| commit | 2c60d9b3f7b7eb1833bc2b803debe8868fd3fbf5 | [log] [tgz] |
|---|---|---|
| author | Scott Graham <scottmg@google.com> | Wed Jan 16 15:41:41 2019 -0800 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Fri Jan 18 18:15:21 2019 +0000 |
| tree | a18e2bdc881dcef37b4db25a53701337d95a58fe | |
| parent | 32b84508ad1226eb3bbefc4c8582d30c12240ed9 [diff] |
[vmo] Avoid assert for very large vmo allocations When a VMO was allocated in the range at the end of the address space, a later attempt to free by range would overflow the end bound, resulting in the last page(s) not being freed. Reduce the maximum size of a VMO so that a full VmPageListNode's span always has an offset that fits in a uint64_t. This bug was found by syzkaller. Minimized repro from cpu's CL at https://fuchsia-review.googlesource.com/c/zircon/+/184607/2: void crasher(void) { const uint64_t kVmoSz = 0xffffffffffff7fff; zx_handle_t vmo; zx_status_t res = zx_vmo_create(kVmoSz, 0, &vmo); if (res != ZX_OK) return; zx_vmo_op_range(vmo, ZX_VMO_OP_COMMIT, kVmoSz - 0x8000, 3, 0, 0); zx_handle_close(vmo); } ZX-2359 #comment [vmo] Avoid assert for very large vmo allocations Test: new cases added to `k ut vm` and `k ut vmpl` Change-Id: I799ef6cfd1629f4a259fd1746d0b0d4e1ef3e32d
Zircon is the core platform that powers the Fuchsia OS. Zircon is composed of a microkernel (source in kernel/...) as well as a small set of userspace services, drivers, and libraries (source in system/...) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation.
The canonical Zircon Git repository is located at: https://fuchsia.googlesource.com/zircon
A read-only mirror of the code is present at: https://github.com/fuchsia-mirror/zircon
The Zircon Kernel provides syscalls to manage processes, threads, virtual memory, inter-process communication, waiting on object state changes, and locking (via futexes).
Currently there are some temporary syscalls that have been used for early bringup work, which will be going away in the future as the long term syscall API/ABI surface is finalized. The expectation is that there will be about 100 syscalls.
Zircon syscalls are generally non-blocking. The wait_one, wait_many port_wait and thread sleep being the notable exceptions.
This page is a non-comprehensive index of the zircon documentation.