1. 07 Jul, 2022 1 commit
  2. 27 Jun, 2022 2 commits
    • Samuel Groß's avatar
      [sandbox] Turn ExternalPointerTag into a template parameter · 8ca93205
      Samuel Groß authored
      The ExternalPointerTags are assumed to be compile-time constants in most
      cases, so turning them into template parameters enforces that. As
      decisions such as whether to use the per-isolate or the shared external
      pointer table are encoded into the tag values, forcing those to be
      compile-time constants guarantees that the compiler will be able to
      inline the correct logic when accessing an external pointer.
      
      With this, there are now two (high-level) ways of accessing external pointer fields from C++: the Read/WriteExternalPointerField methods
      which require the ExternalPointerTag to be a template parameter, and the
      ExternalPointerSlot class which takes the tag as an argument. The latter
      is for example used for snapshot deserialization and by the garbage
      collector (more generally, by the ObjectVisitor::VisitExternalPointer
      method), where the tag is not a compile-time constant.
      
      Finally, this CL also introduces a new ExternalPointerHandle type which
      represents the (opaque) on-heap representation of a reference to an
      entry in an ExternalPointerTable when sandboxing is enabled. Making this
      its own type makes the code a bit more readable.
      
      Bug: v8:10391
      Change-Id: I867b8ce41d15d485f1dc66786f233c710c56afcb
      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/+/3720641Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      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@{#81402}
      8ca93205
    • Samuel Groß's avatar
      [sandbox] Simplify sandbox initialization logic · 39f6787a
      Samuel Groß authored
      Instead of creating smaller sandboxes when the allocation of the virtual
      address space reservation fails, we now create partially-reserved
      sandboxes and halve the reservation size until the initialization
      succeeds. That way, the unreserved part of the sandbox can still be used
      for allocating objects.
      
      Bug: v8:10391
      Change-Id: I89a7790ffcda87ab71cc7b7f1101c0a1c3c62829
      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/+/3714241Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81379}
      39f6787a
  3. 23 Jun, 2022 1 commit
  4. 21 Jun, 2022 1 commit
  5. 20 Jun, 2022 1 commit
  6. 17 Jun, 2022 3 commits
  7. 15 Jun, 2022 2 commits
  8. 10 Jun, 2022 1 commit
  9. 08 Jun, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Implement sandbox crash filter · 059903de
      Samuel Groß authored
      If enabled, a signal handler is installed which intercepts memory access
      violations (e.g. SIGSEGV) and checks whether they occurred inside the
      sandbox address space, in which case the process is terminated cleanly
      as this does not represent a (security) issue with the sandbox. However,
      if the access violation occurred outside the sandbox, the access
      violation is forwarded to the original signal handler.
      
      The filter can be enabled in d8 by specifying
      --enable-sandbox-crash-filter.
      
      Bug: v8:12878
      Change-Id: If9d76267e90ee79ee81ab793d7774afed6226b7c
      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/+/3688408Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80999}
      059903de
  10. 07 Jun, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Treat sandbox reservation failures as OOMs · a072a429
      Samuel Groß authored
      When the sandbox cannot be initialized, it's either because there is not
      enough virtual address space available, or because there is not enough
      memory for the kernel data structures needed for the reservation (this
      typically happens on Windows 7/8 where reserving virtual memory is
      expensive). Both cases should be reported as OOMs, not CHECK failures.
      
      Bug: chromium:1325302
      Change-Id: I17bde9bcd4fbd6e3d54075b8891287c8fb01c1d7
      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/+/3688406
      Auto-Submit: Samuel Groß <saelo@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80975}
      a072a429
  11. 20 May, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Add new Memory Corruption API · 4a12cb10
      Samuel Groß authored
      When enabled, this API exposes a new global 'Sandbox' object which
      contains a number of functions and objects that in effect emulate
      typical memory corruption primitives constructed by exploits. In
      particular, the 'MemoryView' constructor can construct ArrayBuffers
      instances that can corrupt arbitrary memory inside the sandbox. Further,
      the getAddressOf(obj) and getSizeInBytesOf(obj) functions can be used
      respectively to obtain the address (relative to the base of the sandbox)
      and size of any HeapObject that can be accessed from JavaScript.
      
      This API is useful for testing the sandbox, for example to
      facilitate developing PoC sandbox escapes or writing regression tests.
      In the future, it may also be used by custom V8 sandbox fuzzers.
      
      Bug: v8:12878
      Change-Id: I4e420b2ff28bd834b0693f1546942e51c71bfdda
      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/+/3650718Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80659}
      4a12cb10
  12. 16 May, 2022 1 commit
  13. 13 May, 2022 2 commits
  14. 07 Mar, 2022 2 commits
  15. 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
  16. 10 Feb, 2022 1 commit
  17. 01 Feb, 2022 1 commit
  18. 31 Jan, 2022 1 commit
  19. 25 Jan, 2022 1 commit
  20. 20 Jan, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Implement GC for the external pointer table · 4a3e41c5
      Samuel Groß authored
      The external pointer table is now managed by the GC, which marks entries
      that are alive during major GC, then sweeps the table afterwards to free
      all dead entries and build a free list from them. For now, only major GCs
      are supported, Scavenger GCs do not interact with the external pointer table.
      
      In more detail, garbage collection of the external pointer table works
      as follows:
      
      1. The external pointer table now reserves a large region of virtual
         address space for its backing buffer and is then never reallocated,
         only grown in place until the maximum size is reached.
      2. When the GC's marking visitor marks a HeapObject with an external
         pointer as alive, it also marks the corresponding external pointer
         table entry as alive. This can happen on a background thread.
      3. For that, it uses the MSB of each entry in the table to indicate
         whether the entry has been marked or not. This works because the MSB
         is always cleared during the AND-based type check performed when
         accessing an external pointer.
      4. After marking, the external pointer table is swept while the mutator
         is stopped. This builds an inline, singly-linked freelist of all
         newly-dead and previously-free entries.
      5. When allocating an entry from the table, the first entry on the
         freelist is used. If the freelist is empty, the table grows,
         populating the freelist with the new entries.
      6. Every newly-allocated entry is marked as alive, and every store to an
         existing entry also automatically marks that entry as alive (by also
         setting the MSB). This simplifies the design of the table GC with
         regards to concurrency (See ExternalPointerTable::Mark).
      
      Bug: v8:10391
      Change-Id: I8877fdf5576af3761bde65298951bb09e601bd14
      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/+/3359625Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78708}
      4a3e41c5
  21. 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
  22. 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
  23. 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