1. 07 Mar, 2022 1 commit
  2. 16 Feb, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Disallow executable pages inside the sandbox · 6e06d756
      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: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79119}
      6e06d756
  3. 14 Jan, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Improve sandboxed pointer support · 549ee6f3
      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: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78620}
      549ee6f3
  4. 04 Jan, 2022 1 commit
    • Samuel Groß's avatar
      [base] Add VirtualAddressSpace::AllocateGuardRegion · 406d65d3
      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: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78480}
      406d65d3
  5. 15 Dec, 2021 1 commit
    • Samuel Groß's avatar
      V8 Sandbox rebranding · 277fdd1d
      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: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78384}
      277fdd1d
  6. 04 Dec, 2021 1 commit
    • Samuel Groß's avatar
      Introduce VirtualAddressSpace interface · a7cb30b0
      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: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78235}
      a7cb30b0
  7. 02 Dec, 2021 1 commit
    • Samuel Groß's avatar
      Use CagedPointers for ArrayBuffer backing stores · 42ed4928
      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: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78218}
      42ed4928
  8. 29 Oct, 2021 1 commit
    • Samuel Groß's avatar
      Introduce CagedPointer · afd15549
      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: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77614}
      afd15549
  9. 28 Oct, 2021 1 commit
  10. 19 Oct, 2021 1 commit
  11. 15 Oct, 2021 1 commit
  12. 14 Oct, 2021 2 commits
    • Samuel Groß's avatar
      Add special handling for Windows in DetermineAddressSpaceLimit · 72cd8c1a
      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: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77402}
      72cd8c1a
    • Samuel Groß's avatar
      Implement DetermineAddressSpaceLimit() on x64 · 571eca5c
      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: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77393}
      571eca5c
  13. 13 Oct, 2021 1 commit
    • Samuel Groß's avatar
      Reland "Implement a fake virtual memory cage mechanism" · 0aaec6ed
      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: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77378}
      0aaec6ed
  14. 12 Oct, 2021 2 commits
    • Deepti Gandluri's avatar
      Revert "Implement a fake virtual memory cage mechanism" · 1a0b993d
      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}
      1a0b993d
    • Samuel Groß's avatar
      Implement a fake virtual memory cage mechanism · 1ea76c13
      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: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77367}
      1ea76c13
  15. 08 Oct, 2021 1 commit
  16. 07 Oct, 2021 1 commit
    • Samuel Groß's avatar
      Add PageInitializationMode enum for the BoundedPageAllocator · 18c37d32
      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: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77285}
      18c37d32
  17. 20 Sep, 2021 1 commit
    • Samuel Groß's avatar
      Reduce the size of the virtual memory cage if necessary · 95ca07c8
      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: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76948}
      95ca07c8
  18. 17 Sep, 2021 1 commit
  19. 11 Aug, 2021 1 commit