- 26 Apr, 2022 1 commit
-
-
Igor Sheludko authored
It's necessary to support fast W^X permission switching on MacOS on ARM64 ("Apple M1"/Apple Silicon) where permission modification of RWX pages to anything else is prohibited. On all the other architectures/platforms RecommitPages() is equivalent to SetPermissions(). The new API will be used in a follow-up CLs. Bug: v8:12797 Change-Id: Id0d8b8c42c81b80cd8fa6b47c227680d7d1f9b10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606231Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Samuel Groß <saelo@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#80190}
-
- 07 Mar, 2022 1 commit
-
-
Samuel Groß authored
Instead of returning a boolean success/failure value, the Free* methods of the VirtualAddressSpace API now terminate the process on failure, as this implies a bug in the caller. This is simpler than CHECKing for success in all callers and also provides more details about the possible cause of the failure. Bug: v8:12656 Change-Id: I5b469ae2c564068cff74e60b7e98f6a4776a239d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3506992Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#79388}
-
- 16 Feb, 2022 2 commits
-
-
Samuel Groß authored
This API allows allocating shared memory mappings inside a virtual address space from a platform-specific handle to a shared memory object. This will make it possible to allocate shared memory inside the sandbox, for example as backing memory for ArrayBuffers. Bug: chromium:1218005 Change-Id: I4f1f50baec50734e846496cff78046e4fffe75c5 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383777Reviewed-by: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#79123}
-
Samuel Groß authored
These should not be allowed inside the sandbox as they could be corrupted by an attacker, thus posing a security risk. Furthermore, executable pages require MAP_JIT on macOS, which causes fork() to become excessively slow, in turn causing tests to time out. Due to this, the sandbox now requires the external code space. In addition, this CL adds a max_page_permissions member to the VirtualAddressSpace API to make it possible to verify the maximum permissions of a subspace. Bug: v8:10391 Change-Id: Ib9562ecff6f018696bfa25143113d8583d1ec6cd Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460406Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#79119}
-
- 04 Jan, 2022 1 commit
-
-
Samuel Groß authored
Previously, guard regions were created by allocating pages with PROT_NONE and relying on an allocation hint. This could fail however, for example on Fuchsia (where it would allocate a VMO to back the guard region) and possibly on Windows (where a placeholder mapping was replaced by a "real" mapping). Introducing an explicit VirtualAddressSpace::AllocateGuardRegion routine now makes this operation more efficient and effectively guarantees that it cannot fail if used correctly: in a regular subspace, there is no need to allocate anything when creating guard regions since the address space reservation backing the subspace is guaranteed to be inaccessible when no pages are allocated in it. Bug: chromium:1218005 Change-Id: I6945f17616b6b8dad47241af96d4cb1f660e8858 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366237Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78480}
-
- 04 Dec, 2021 1 commit
-
-
Samuel Groß authored
This interface is meant to eventually replace the existing v8::PageAllocator interface. Beyond general refactoring of the PageAllocator APIs, the new interface now supports the concept of (contiguous) address space reservations, which previously had to be implemented through page allocations. These reservations now make better use of provided OS primitives on Fuchsia (VMARs) and Windows (placeholder mappings) and can be used to back many of the cages and virtual memory regions that V8 creates. The new interface is not yet stable and may change at any time without deprecating the old version first. Bug: chromium:1218005 Change-Id: I295253c42e04cf311393c5dab9f8c06bd7451ce3 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301475 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78235}
-