1. 26 Apr, 2022 1 commit
  2. 25 Apr, 2022 1 commit
  3. 25 Feb, 2022 1 commit
  4. 19 Nov, 2021 1 commit
  5. 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
  6. 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
  7. 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
  8. 17 Aug, 2021 1 commit
  9. 11 Aug, 2021 1 commit
  10. 09 Aug, 2021 1 commit
  11. 29 Jul, 2021 1 commit
  12. 31 Jul, 2020 1 commit
    • Dan Elphick's avatar
      [heap] Share RO_SPACE pages with pointer compression · c7d22c49
      Dan Elphick authored
      This allows the configuration v8_enable_shared_ro_heap and
      v8_enable_pointer_compression on Linux and Android, although it still
      defaults to off.
      
      When pointer compression and read-only heap sharing are enabled, sharing
      is achieved by allocating ReadOnlyPages in shared memory that are
      retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are
      then remapped into the address space of the Isolate ultimately using
      mremap.
      
      To simplify the creation process the ReadOnlySpace memory for the first
      Isolate is created as before without any sharing. It is only when the
      ReadOnlySpace memory has been finalized that the shared memory is
      allocated and has its contents copied into it. The original memory is
      then released (with PC this means it's just released back to the
      BoundedPageAllocator) and immediately re-allocated as a shared mapping.
      
      Because we would like to make v8_enable_shared_ro_heap default to true
      at some point but can't make this conditional on the value returned by
      a method in the code we are yet to compile, the code required for
      sharing has been mostly changed to use ifs with
      ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where
      a compile error would result due to the absence of a class members
      without sharing. IsReadOnlySpaceShared() will evaluate
      CanAllocateSharedPages in the platform PageAllocator (with pointer
      compression and sharing enabled) once and cache that value so sharing
      cannot be toggled during the lifetime of the process.
      
      Bug: v8:10454
      Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69174}
      c7d22c49
  13. 30 Oct, 2018 1 commit
  14. 22 Oct, 2018 1 commit
  15. 12 Oct, 2018 1 commit
  16. 08 Oct, 2018 1 commit
  17. 28 Sep, 2018 1 commit
  18. 15 Sep, 2018 1 commit
  19. 12 Sep, 2018 1 commit
  20. 10 Sep, 2018 1 commit