- 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 1 commit
-
-
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}
-
- 14 Jan, 2022 1 commit
-
-
Samuel Groß authored
This CL removes the global IsValidBackingStorePointer function and turns the DCHECKs that ensure that sandboxed pointers point into the sandbox, which essentially cover the same condition, into CHECKs. This is mostly to facilitate debugging during the initial rollout, and the CHECKs can later be turned back into DCHECKs. In addition, this CL adds a fallback to a partially-reserved sandbox when sandboxed pointers are enabled and when the regular initialization fails. Bug: chromium:1218005 Change-Id: I75526f1a00ddb9095ae0e797dc9bb80a210f867b 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/+/3367617Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78620}
-
- 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}
-
- 15 Dec, 2021 1 commit
-
-
Samuel Groß authored
This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 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/+/3322981Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
-
- 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}
-
- 02 Dec, 2021 1 commit
-
-
Samuel Groß authored
This CL turns references to ArrayBuffer backing stores from JSArrayBuffers, JSTypedArrays, and JSDataViews into CagedPointers when those are enabled. CagedPointers cannot generally represent nullptr, as NULL usually lies outside the cage. As such, nullptr backing stores are replaced with a special empty backing store value, which, in the current implementation, points to the end of the cage, right in front of the trailing guard regions. Due to this, it is no longer correct to compare a backing store pointer against nullptr. Bug: chromium:1218005 Change-Id: I4a6c7a82aabb4debcb6bb2babe4035ba2da8e79f 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/+/3244419 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78218}
-
- 29 Oct, 2021 1 commit
-
-
Samuel Groß authored
A CagedPointer is guaranteed to point into the Virtual Memory Cage and will for example be used for ArrayBuffer backing stores when the heap sandbox is enabled. In the current implementation, CagedPointers are stored as offsets from the cage base, shifted to the left. Because the cage base address is usually available in a register, accessing a CagedPointer is very efficient, requiring only an additional shift and add operation. Bug: chromium:1218005 Change-Id: Ifc8c088e3862400672051a8c52840514dee2911f 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/+/3123417Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77614}
-
- 28 Oct, 2021 1 commit
-
-
Samuel Groß authored
Bug: chromium:1263504 Change-Id: I32091478eb1662b72e0b9507e7cd17314cb277d7 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247634Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77588}
-
- 19 Oct, 2021 1 commit
-
-
Samuel Groß authored
Bug: v8:10391 Change-Id: Ia123d8034c4ade76c9843df5d947fdc4ee3d8e35 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/+/3226337Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77454}
-
- 15 Oct, 2021 1 commit
-
-
Milad Fa authored
Bug: chromium:1218005 Change-Id: I1c9aae03e460155002dfa2483c37cec4f50ec566 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226782Reviewed-by: Samuel Groß <saelo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/main@{#77419}
-
- 14 Oct, 2021 2 commits
-
-
Samuel Groß authored
On Windows pre 8.1, userspace is limited to 8TB of virtual address space. Take that into account when determining the size and/or placement of the virtual memory cage. Bug: chromium:1218005 Change-Id: Idda94534cad67dc2db77e9ba459e3a4b239dac2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3222763Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77402}
-
Samuel Groß authored
This function tries to determine the number of virtual address bits available on the current CPU and with that the maximum size of the userspace address space. On x64, it can be implemented through CPUID. The result of this function is now used in two ways: first, it limits the maximum size of the virtual memory cage, currently to a quarter of the address space. Second, it influences the placement of fake cages, which are attempted to be placed into the lower half of the address space so that they are followed by large amounts of (hopefully) unused but addressable virtual memory in which pages can be allocated. Bug: chromium:1218005 Change-Id: I0edc5d241d899f16dbc47492fa1534b6aaa4aa13 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220348 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#77393}
-
- 13 Oct, 2021 1 commit
-
-
Samuel Groß authored
This is a reland of 1ea76c13 Disabled the failing test on Fuchsia until its PageAllocator respects allocation hints. Original change's description: > Implement a fake virtual memory cage mechanism > > On operating systems where reserving virtual address space is expensive, > notably Windows pre 8.1, it is not possible to create a proper virtual > memory cage. In order to still be able to reference caged objects > through offsets from the cage base on these systems, this CL introduces > a fake cage mechanism. When the fake cage is used, most of the virtual > memory for the cage is not actually reserved. Instead, the cage's page > allocator simply relies on hints to the OS to obtain pages inside the > cage. This does, however, not provide the same security benefits as a > real cage as unrelated allocations might end up inside the cage. > > Bug: chromium:1218005 > Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3 > 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/+/3217200 > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77367} Bug: chromium:1218005 Change-Id: I2ed95d121db164679c38085115e8fa92690c057e 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/+/3220151Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77378}
-
- 12 Oct, 2021 2 commits
-
-
Deepti Gandluri authored
This reverts commit 1ea76c13. Reason for revert: The unit test added fails on the Fuchsia bot https://ci.chromium.org/p/v8/builders/ci/V8%20Fuchsia/25976? Original change's description: > Implement a fake virtual memory cage mechanism > > On operating systems where reserving virtual address space is expensive, > notably Windows pre 8.1, it is not possible to create a proper virtual > memory cage. In order to still be able to reference caged objects > through offsets from the cage base on these systems, this CL introduces > a fake cage mechanism. When the fake cage is used, most of the virtual > memory for the cage is not actually reserved. Instead, the cage's page > allocator simply relies on hints to the OS to obtain pages inside the > cage. This does, however, not provide the same security benefits as a > real cage as unrelated allocations might end up inside the cage. > > Bug: chromium:1218005 > Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3 > 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/+/3217200 > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77367} Bug: chromium:1218005 Change-Id: I541bb9656ab2a6a080c2a30d372226fcc5c95391 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219086 Auto-Submit: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/main@{#77368}
-
Samuel Groß authored
On operating systems where reserving virtual address space is expensive, notably Windows pre 8.1, it is not possible to create a proper virtual memory cage. In order to still be able to reference caged objects through offsets from the cage base on these systems, this CL introduces a fake cage mechanism. When the fake cage is used, most of the virtual memory for the cage is not actually reserved. Instead, the cage's page allocator simply relies on hints to the OS to obtain pages inside the cage. This does, however, not provide the same security benefits as a real cage as unrelated allocations might end up inside the cage. Bug: chromium:1218005 Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3 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/+/3217200 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77367}
-
- 08 Oct, 2021 1 commit
-
-
Samuel Groß authored
On Windows pre 8.1, reserving a large virtual memory region for the cage is too expensive as it (apparently) creates PTEs. As such, we can only create a cage with the minimum size and without guard regions. Bug: chromium:1218005 Change-Id: Ib19b9a08f8c965d9739c1d539a0153b32a290826 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3212507Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77296}
-
- 07 Oct, 2021 1 commit
-
-
Samuel Groß authored
Currently, when compiling with V8_VIRTUAL_MEMORY_CAGE enabled, the behavior of the BoundedPageAllocator changes from simply making freed pages inaccessible to decommitting them, which guarantees that they will be zero-initialized after the next allocation. As this seems to cause some performance regressions on Mac, this CL introduces a new enum that specifies how the allocator should behave: kAllocatedPagesMustBeZeroInitialized causes the pages to be decommitted during FreePages() and ReleasePages() and thus guarantees zero-initialization during AllocPages(). kAllocatedPagesCanBeUninitialized only causes the pages to be made inaccessible, and so does not generally guarantee zero-initialization for AllocPages(). Finally, this CL also removes some dead code in allocation.cc. Bug: chromium:1257089 Change-Id: I53fa52c8913df869bee2b536efe252780d1ad893 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208812 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#77285}
-
- 20 Sep, 2021 1 commit
-
-
Samuel Groß authored
At least for the initial rollout, we will gracefully handle cage reservation failures by shrinking the size of the cage until the reservation succeeds or the size drops below the mimimum cage size. This will allow collecting statistics on how often cage reservation failures occur in practice for different cage sizes, which will in turn influence the decision on how to handle them in the future. Bug: chromium:1218005 Change-Id: Ica58951ba51ac01bc2c387b34dfc8d9051ed4d75 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168347Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#76948}
-
- 17 Sep, 2021 1 commit
-
-
Samuel Groß authored
Instead of explicitely splitting the cage into two separate regions, we now just create a single BoundedPageAllocator to manage the entire address range of the cage, then allocate the first 4GB for the pointer compression cage. Bug: chromium:1218005 Change-Id: I02c53ca8b6dda9074ae6caccc74c32bd6271d4d2 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162044Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#76900}
-
- 11 Aug, 2021 1 commit
-
-
Samuel Groß authored
When this is enabled, v8 reserves a large region of virtual address space during initialization, at the start of which it will place its 4GB pointer compression cage. The remainder of the cage is used to store ArrayBuffer backing stores and WASM memory buffers. This will later allow referencing these buffers from inside V8 through offsets from the cage base rather than through raw pointers. Bug: chromium:1218005 Change-Id: I300094b07f64985217104b14c320cc019f8438af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010195Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@google.com> Cr-Commit-Position: refs/heads/master@{#76234}
-