1. 07 Jul, 2022 1 commit
  2. 09 Jun, 2022 1 commit
    • Igor Sheludko's avatar
      [ext-code-space] Fix CodeRange allocation logic · 36e47253
      Igor Sheludko authored
      ... which required unnecessarily big alignment for the base on Windows.
      
      Drive-by: adapt hint usage in VirtualMemoryCage::InitReservation() for
      non-zero kReservedCodeRangePages and hint values provided by
      CodeRangeAddressHint::GetAddressHint() which might be the start address
      of the previously reserved region which in turn already includes the
      kReservedCodeRangePages pages.
      
      Bug: v8:11880, v8:12942
      Change-Id: Ieee44ed2bdfc77aa8efaef449221caaae1f0f08f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695382Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81026}
      36e47253
  3. 13 May, 2022 1 commit
  4. 28 Apr, 2022 1 commit
    • Igor Sheludko's avatar
      Reland "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)" · 449ece38
      Igor Sheludko authored
      This is a reland of commit 9d31f866
      There were issues with --future flag implications on M1.
      
      Original change's description:
      > [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
      >
      > ... for V8 code space. The feature is currently disabled.
      >
      > In order to use fast W^X permission switching we must allocate
      > executable pages with readable writable executable permissions (RWX).
      > However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
      > permission changing of RWX memory pages. This means that the code page
      > headers must be allocated with RWX permissions too because otherwise
      > it wouldn't be possible to allocate a large code page over the freed
      > regular code page and vice versa.
      >
      > When enabled, the new machinery works as follows:
      >
      > 1) when memory region is reserved for allocating executable pages, the
      >    whole region is committed with RWX permissions and then decommitted,
      > 2) since reconfiguration of RWX page permissions is not allowed on
      >    MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
      >    to change them,
      > 3) the request to set RWX permissions in the executable page region
      >    just recommits the pages without changing permissions (see (1), they
      >    were already allocated as RWX and then discarded),
      > 4) in order to make executable pages inaccessible one must use
      >    OS::DiscardSystemPages() instead of OS::DecommitPages() or
      >    setting permissions to kNoAccess because the latter two are not
      >    allowed by the MacOS (see (2)).
      > 5) since code space page headers are allocated as RWX pages it's also
      >    necessary to switch between W^X modes when updating the data in the
      >    page headers (i.e. when marking, updating stats, wiring pages in
      >    lists, etc.). The new CodePageHeaderModificationScope class is used
      >    in the respective places. On unrelated configurations it's a no-op.
      >
      > The fast permission switching can't be used for V8 configuration with
      > enabled pointer compression and disabled external code space because
      > a) the pointer compression cage has to be reserved with MAP_JIT flag
      >    which is too expensive,
      > b) in case of shared pointer compression cage if the code range will
      >    be deleted while the cage is still alive then attempt to configure
      >    permissions of pages that were previously set to RWX will fail.
      >
      > This also CL extends the unmapper unit tests with permissions tracking
      > for discarded pages.
      >
      > Bug: v8:12797
      > Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80238}
      
      Bug: v8:12797
      Change-Id: I0fe86666f31bad37d7074e217555c95900d2afba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610433Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80259}
      449ece38
  5. 27 Apr, 2022 2 commits
    • Adam Klein's avatar
      Revert "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)" · 10807c9f
      Adam Klein authored
      This reverts commit 9d31f866.
      
      Reason for revert: crashes on Mac/arm64 bots:
      https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20debug/5923/overview
      
      Original change's description:
      > [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
      >
      > ... for V8 code space. The feature is currently disabled.
      >
      > In order to use fast W^X permission switching we must allocate
      > executable pages with readable writable executable permissions (RWX).
      > However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
      > permission changing of RWX memory pages. This means that the code page
      > headers must be allocated with RWX permissions too because otherwise
      > it wouldn't be possible to allocate a large code page over the freed
      > regular code page and vice versa.
      >
      > When enabled, the new machinery works as follows:
      >
      > 1) when memory region is reserved for allocating executable pages, the
      >    whole region is committed with RWX permissions and then decommitted,
      > 2) since reconfiguration of RWX page permissions is not allowed on
      >    MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
      >    to change them,
      > 3) the request to set RWX permissions in the executable page region
      >    just recommits the pages without changing permissions (see (1), they
      >    were already allocated as RWX and then discarded),
      > 4) in order to make executable pages inaccessible one must use
      >    OS::DiscardSystemPages() instead of OS::DecommitPages() or
      >    setting permissions to kNoAccess because the latter two are not
      >    allowed by the MacOS (see (2)).
      > 5) since code space page headers are allocated as RWX pages it's also
      >    necessary to switch between W^X modes when updating the data in the
      >    page headers (i.e. when marking, updating stats, wiring pages in
      >    lists, etc.). The new CodePageHeaderModificationScope class is used
      >    in the respective places. On unrelated configurations it's a no-op.
      >
      > The fast permission switching can't be used for V8 configuration with
      > enabled pointer compression and disabled external code space because
      > a) the pointer compression cage has to be reserved with MAP_JIT flag
      >    which is too expensive,
      > b) in case of shared pointer compression cage if the code range will
      >    be deleted while the cage is still alive then attempt to configure
      >    permissions of pages that were previously set to RWX will fail.
      >
      > This also CL extends the unmapper unit tests with permissions tracking
      > for discarded pages.
      >
      > Bug: v8:12797
      > Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80238}
      
      Bug: v8:12797
      Change-Id: Ic07948e036db36326d464a2a901d052aa060a406
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3611665
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80239}
      10807c9f
    • Igor Sheludko's avatar
      [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1) · 9d31f866
      Igor Sheludko authored
      ... for V8 code space. The feature is currently disabled.
      
      In order to use fast W^X permission switching we must allocate
      executable pages with readable writable executable permissions (RWX).
      However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
      permission changing of RWX memory pages. This means that the code page
      headers must be allocated with RWX permissions too because otherwise
      it wouldn't be possible to allocate a large code page over the freed
      regular code page and vice versa.
      
      When enabled, the new machinery works as follows:
      
      1) when memory region is reserved for allocating executable pages, the
         whole region is committed with RWX permissions and then decommitted,
      2) since reconfiguration of RWX page permissions is not allowed on
         MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
         to change them,
      3) the request to set RWX permissions in the executable page region
         just recommits the pages without changing permissions (see (1), they
         were already allocated as RWX and then discarded),
      4) in order to make executable pages inaccessible one must use
         OS::DiscardSystemPages() instead of OS::DecommitPages() or
         setting permissions to kNoAccess because the latter two are not
         allowed by the MacOS (see (2)).
      5) since code space page headers are allocated as RWX pages it's also
         necessary to switch between W^X modes when updating the data in the
         page headers (i.e. when marking, updating stats, wiring pages in
         lists, etc.). The new CodePageHeaderModificationScope class is used
         in the respective places. On unrelated configurations it's a no-op.
      
      The fast permission switching can't be used for V8 configuration with
      enabled pointer compression and disabled external code space because
      a) the pointer compression cage has to be reserved with MAP_JIT flag
         which is too expensive,
      b) in case of shared pointer compression cage if the code range will
         be deleted while the cage is still alive then attempt to configure
         permissions of pages that were previously set to RWX will fail.
      
      This also CL extends the unmapper unit tests with permissions tracking
      for discarded pages.
      
      Bug: v8:12797
      Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80238}
      9d31f866
  6. 26 Apr, 2022 1 commit
  7. 25 Apr, 2022 1 commit
  8. 24 Feb, 2022 1 commit
    • Clemens Backes's avatar
      Fail earlier on FreePages · 205fb295
      Clemens Backes authored
      {FreePages} is never expected to fail, and each caller wraps the call in
      a CHECK macro. In order to learn more about failures, this CL moves the
      CHECK inside of {::FreePages}, to fail whenever the {PageAllocator}
      fails to free pages.
      
      As a next step, I'll audit our {PageAllocator} implementations to ensure
      that none of them return {false} for {FreePages}. Note that this is
      already the case for the gin platform (chromium).
      
      R=mlippautz@chromium.org
      
      Bug: v8:12656, chromium:1299735
      Change-Id: Ib61be6cc8da0110ead2db1ad005728bd061e0243
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3484321Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79248}
      205fb295
  9. 26 Jan, 2022 1 commit
    • Igor Sheludko's avatar
      [ext-code-space] Fix CodeRange allocation logic · 695afbff
      Igor Sheludko authored
      1) when generating short builtin calls/jumps assemblers should use the
         offset from the CodeRange base rather than the start of the code
         range reservation because otherwise it's not guaranteed that the
         PC-relative offset will fit into architecture's constraints.
         The code range reservation start could be different from the code
         range base in the following cases:
           * when the "base bias size" is non-zero (on Windows 64),
           * when we ended up over-reserving the address space for the code
             range, which happens as a last resort to fulfil the CodeRange
             alignment requirements.
         See the VirtualMemoryCage description for details.
      
      Drive-by fixes:
      2) in case of over-reserving address space for external code range,
         the pre-calculated hint for where the remapped embedded builtins
         should be copied to was outside of the allocatable CodeRange region
         and thus useless. The fix is to use the allocatable region instead
         of the reservation region when calculating the hint.
      3) when allocating CodeRange with zero base bias size we can create
         the VirtualMemory reservation from the first attempt simply by
         passing the required base alignment to the VirtualMemory
         constructor.
      
      Bug: v8:11880, chromium:1290591
      Change-Id: If341418947e2170d967e22b38bcc371594939c1c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3412089Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78772}
      695afbff
  10. 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
  11. 06 Dec, 2021 1 commit
  12. 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
  13. 11 Nov, 2021 1 commit
  14. 19 Oct, 2021 1 commit
  15. 14 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. 06 Oct, 2021 1 commit
  18. 23 Sep, 2021 1 commit
    • Anton Bikineev's avatar
      [zone] Provide a way to configure allocator for zone backings · e262e1cb
      Anton Bikineev authored
      The CL provides a way for the embedder to hook in a special malloc-like
      allocator that will be used for zone allocations.
      
      An alternative approach would be to use weak functions with branches,
      checking whether the functions were available at link-time. Those
      branches could be optimized away with LTOs, so they would essentially
      be free. However, the weak function approach is not portable (e.g.
      there is no easy way to emulate it with msvc). The approach can be
      revisited if indirect call turns out to be expensive (e.g. on hardware
      with weak branch target predictors).
      
      The CL is a prerequisite for running PCScan in the renderer process.
      
      Bug: chromium:1249550
      Change-Id: I221dcb2486c13e8e6e6761839ba391978319bde4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172760Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77012}
      e262e1cb
  19. 17 Sep, 2021 1 commit
  20. 11 Aug, 2021 1 commit
  21. 19 Jul, 2021 1 commit
  22. 01 Jul, 2021 1 commit
  23. 18 Jun, 2021 1 commit
  24. 30 Apr, 2021 1 commit
  25. 26 Apr, 2021 1 commit
  26. 19 Apr, 2021 1 commit
  27. 17 Nov, 2020 1 commit
  28. 07 Oct, 2020 1 commit
  29. 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
  30. 16 Jan, 2020 1 commit
  31. 16 Sep, 2019 1 commit
  32. 04 Sep, 2019 2 commits
  33. 15 Jul, 2019 1 commit
    • Clemens Hammacher's avatar
      [utils] Fix Malloced implementation · 2d277529
      Clemens Hammacher authored
      According to the specification, class-specific {operator new} and
      {operator delete} should be static methods. Interestingly, if the
      {static} keyword is missing, the methods are implicitly static anyway.
      This is confusing, so this CL adds the {static} keywords explicitly.
      It also removes the redundant {Malloced::New} and {Malloced::Delete}
      methods.
      
      R=mlippautz@chromium.org
      
      Bug: v8:9396
      Change-Id: I1db7c87b816567cc1a9153d0b18e3dd4ae81dd6f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700080Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62703}
      2d277529
  34. 24 May, 2019 1 commit
  35. 23 May, 2019 1 commit
  36. 21 May, 2019 1 commit
  37. 06 May, 2019 1 commit
  38. 29 Apr, 2019 1 commit