1. 14 Jul, 2021 1 commit
  2. 13 Jul, 2021 4 commits
    • Clemens Backes's avatar
      Reland "[wasm] Fix fallback from PKU to mprotect" · 7f58edd5
      Clemens Backes authored
      This is a reland of dacce720
      
      Original change's description:
      > [wasm] Fix fallback from PKU to mprotect
      >
      > The {WasmCodeManager::SetThreadWritable} method would return true if
      > called in a nested scope, even if PKU is not available. The caller
      > cannot tell then whether permission switching happened or not.
      >
      > This CL refactors the code to do an explicit check for PKU support, and
      > removes the boolean return value from {SetThreadWritable}.
      >
      > R=jkummerow@chromium.org
      >
      > Bug: v8:11959, v8:11974
      > Change-Id: I2d45f1fa240305c6f92f63cdf190131d637bfe95
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021383
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75699}
      
      Bug: v8:11959, v8:11974
      Change-Id: I7086aa3f1cd12615e6f12bbd061084ecd325eb11
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021180Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75707}
      7f58edd5
    • Clemens Backes's avatar
      Revert "[wasm] Fix fallback from PKU to mprotect" · f4f14bbb
      Clemens Backes authored
      This reverts commit dacce720.
      
      Reason for revert: Needs a fix.
      
      Original change's description:
      > [wasm] Fix fallback from PKU to mprotect
      >
      > The {WasmCodeManager::SetThreadWritable} method would return true if
      > called in a nested scope, even if PKU is not available. The caller
      > cannot tell then whether permission switching happened or not.
      >
      > This CL refactors the code to do an explicit check for PKU support, and
      > removes the boolean return value from {SetThreadWritable}.
      >
      > R=​jkummerow@chromium.org
      >
      > Bug: v8:11959, v8:11974
      > Change-Id: I2d45f1fa240305c6f92f63cdf190131d637bfe95
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021383
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75699}
      
      Bug: v8:11959, v8:11974
      Change-Id: I199cf6dd6e12a209649fcf86f922e2500b50bbde
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021179
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#75700}
      f4f14bbb
    • Clemens Backes's avatar
      [wasm] Fix fallback from PKU to mprotect · dacce720
      Clemens Backes authored
      The {WasmCodeManager::SetThreadWritable} method would return true if
      called in a nested scope, even if PKU is not available. The caller
      cannot tell then whether permission switching happened or not.
      
      This CL refactors the code to do an explicit check for PKU support, and
      removes the boolean return value from {SetThreadWritable}.
      
      R=jkummerow@chromium.org
      
      Bug: v8:11959, v8:11974
      Change-Id: I2d45f1fa240305c6f92f63cdf190131d637bfe95
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021383
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75699}
      dacce720
    • Clemens Backes's avatar
      [wasm] Move SetThreadWritable to the WasmCodeManager · 29d7cca5
      Clemens Backes authored
      Since PKU-based switching always switches the permissions for all wasm
      code memory in the process, the method should not be on the
      {NativeModule} or {WasmCodeAllocator}, but instead on the process-wide
      {WasmCodeManager}.
      
      R=jkummerow@chromium.org
      
      Bug: v8:11974
      Change-Id: I75a82e51401b2572977c134077e1669cf5077049
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021382
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75694}
      29d7cca5
  3. 05 Jul, 2021 1 commit
  4. 24 Jun, 2021 2 commits
  5. 22 Jun, 2021 1 commit
    • Clemens Backes's avatar
      Reland "[wasm] Provide a global WasmCodeManager" · 4e19455b
      Clemens Backes authored
      This is a reland of 0f90a2aa.
      The issue was inverted destructor order between WasmCodeManager and
      WasmEngine. WasmEngine has to be destructed first, because it contains
      a barrier to ensure that background compile threads finished before
      global state is being destructed.
      
      Original change's description:
      > [wasm] Provide a global WasmCodeManager
      >
      > The WasmCodeManager was part of the WasmEngine so far, but there is only
      > exactly one WasmEngine. Hence we can pull it out, and also remove the
      > pointer in the WasmCodeAllocator.
      >
      > The argument passed from the single constructor call is now inlined in
      > the constructor itself.
      >
      > Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just
      > "CommitPageSize()".
      >
      > R=jkummerow@chromium.org
      >
      > Bug: v8:11879
      > Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75270}
      
      Bug: v8:11879
      Change-Id: I0eaa2395f5c1e30f3f7303c5f3df70c227b74d3d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2975859
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75289}
      4e19455b
  6. 21 Jun, 2021 4 commits
    • Maya Lekova's avatar
      Revert "[wasm] Provide a global WasmCodeManager" · c46e8205
      Maya Lekova authored
      This reverts commit 0f90a2aa.
      
      Reason for revert: Breaks MSAN, please see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/38941/overview
      
      Original change's description:
      > [wasm] Provide a global WasmCodeManager
      >
      > The WasmCodeManager was part of the WasmEngine so far, but there is only
      > exactly one WasmEngine. Hence we can pull it out, and also remove the
      > pointer in the WasmCodeAllocator.
      >
      > The argument passed from the single constructor call is now inlined in
      > the constructor itself.
      >
      > Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just
      > "CommitPageSize()".
      >
      > R=​jkummerow@chromium.org
      >
      > Bug: v8:11879
      > Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75270}
      
      Bug: v8:11879
      Change-Id: I110eec313762d73073f530aec7cf0be82c4db344
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972921
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#75274}
      c46e8205
    • Daniel Lehmann's avatar
      [wasm] Merge code space write scope implementations · 8a3c4881
      Daniel Lehmann authored
      Merges `NativeModuleModificationScope` (with an implementation using
      Intel PKU, if available, and mprotect otherwise) and
      `CodeSpaceWriteScope` (for Apple Silicon, where switching to RWX with
      mprotect is disallowed anyway, so MAP_JIT and thread-local switching
      must be used).
      
      Because `CodeSpaceWriteScope` sounded better (and is shorter), we kept
      its name (which unfortunately makes the diff a bit harder to read).
      
      R=clemensb@chromium.org
      CC=jkummerow@chromium.org
      
      Bug: v8:11714
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Change-Id: Ib2a7d18e72797a725ed34b904c70769166d811dd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972911Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Daniel Lehmann <dlehmann@google.com>
      Cr-Commit-Position: refs/heads/master@{#75272}
      8a3c4881
    • Clemens Backes's avatar
      [wasm] Provide a global WasmCodeManager · 0f90a2aa
      Clemens Backes authored
      The WasmCodeManager was part of the WasmEngine so far, but there is only
      exactly one WasmEngine. Hence we can pull it out, and also remove the
      pointer in the WasmCodeAllocator.
      
      The argument passed from the single constructor call is now inlined in
      the constructor itself.
      
      Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just
      "CommitPageSize()".
      
      R=jkummerow@chromium.org
      
      Bug: v8:11879
      Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75270}
      0f90a2aa
    • Daniel Lehmann's avatar
      [wasm] Move NativeModuleModificationScope impl · 2ef8f917
      Daniel Lehmann authored
      In an effort to merge `CODE_SPACE_WRITE_SCOPE` and
      `NativeModuleModificationScope`, this CL moves the interface and
      implementation of the latter into code-space-access.{h,cc}, where the
      former already lives. No other changes to the code itself.
      
      R=clemensb@chromium.org
      CC=jkummerow@chromium.org
      
      Bug: v8:11714
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Change-Id: I1aabce26f2033430523a7a3a0a4864e7267bee21
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972803Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Daniel Lehmann <dlehmann@google.com>
      Cr-Commit-Position: refs/heads/master@{#75267}
      2ef8f917
  7. 18 Jun, 2021 2 commits
  8. 16 Jun, 2021 1 commit
  9. 15 Jun, 2021 1 commit
  10. 14 Jun, 2021 2 commits
  11. 07 Jun, 2021 2 commits
  12. 02 Jun, 2021 2 commits
  13. 27 May, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm-gc] Implement array.copy (experimental) · dfdc8f68
      Manos Koukoutos authored
      Changes:
      - Add --experimental-wasm-gc-experiments flag.
      - Add array.copy opcode. Implement it in decoding and code generation
        behind the new flag.
      - Add WasmCodeBuilder::BoundsCheckArrayCopy. Move BoundsCheckArray to
        the private section.
      - Add WasmArrayCopy and WasmArrayCopyWithChecks builtin.
      - Add WasmArrayCopy runtime function.
      - Add WasmArray::ElementSlot.
      - Always print two hex digits in CHECK_PROTOTYPE_OPCODE.
      - In test-gc, print the thrown-error message if the function should not
        throw.
      - In test-gc, add GetResultObject with one argument.
      
      Bug: v8:7748
      Change-Id: I58f4d37e254154596cdef5e78482b55260dd3782
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912729
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74806}
      dfdc8f68
  14. 26 May, 2021 1 commit
  15. 25 May, 2021 1 commit
  16. 20 May, 2021 1 commit
  17. 19 May, 2021 1 commit
  18. 18 May, 2021 1 commit
  19. 17 May, 2021 1 commit
  20. 11 May, 2021 1 commit
    • Daniel Lehmann's avatar
      [wasm] Use PKUs for code space write protection · 826642c7
      Daniel Lehmann authored
      This is the second CL in a line of two to implement PKU-based
      WebAssembly code space write protection. The first CL added two
      low-level PKU functions; this CL uses them to grant/withdraw writable
      permissions, local to each thread that wants to modify the code space.
      
      In particular, when {--wasm-memory-protection-keys} is enabled, we first
      associate a memory protection key with all code pages, which by
      default does not allow any write access. Then, before each location that
      needs to modify the code space, we open
      {NativeModuleModificationScope}s (which are already present for
      mprotect-based write protection). When the PKU flag is given, this then
      first tries to set permissions of a memory protection key (which is
      fast), and otherwise when {--wasm-write-protect-code-memory} is enabled,
      falls back to mprotect-based write protection (which is much more
      expensive and also not thread-local, but for the whole process).
      
      R=clemensb@chromium.org
      
      Bug: v8:11714
      Change-Id: I3527906a8d9f776ed44c8d5db52539e78e1c52fd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2882800
      Commit-Queue: Daniel Lehmann <dlehmann@google.com>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74501}
      826642c7
  21. 07 May, 2021 1 commit
    • Daniel Lehmann's avatar
      [wasm] Add PKU flag and alloc/free functions · a0a5aeec
      Daniel Lehmann authored
      To enforce W^X for the WebAssembly code space, we want to explore using
      Intel memory protection keys for userspace, also known as MPK, PKEYs, or
      PKU. Instead of flipping page protection flags with mprotect (which
      incurs a high syscall overhead; and which switches flags for the whole
      process), with PKU we associate a key with each page once and then
      change the permissions of that key with a fast thread-local register
      write. That is, this gives both finger-grained permissions (per-thread)
      and more performance.
      
      This CL is starts experimenting with PKUs by
      (1) adding a flag to turn on prototype PKU support; and if set to true
      (2) allocates a protection key once per {WasmCodeManager} in x64 Linux
      systems.
      
      This is a partial reland of https://crrev.com/c/2850932, which was
      reverted due to an added histogram failing Chromium integration.
      Since the histogram (to record PKU support) is independent of the
      functionality in this CL, we split it out into its own CL (to come).
      
      R=clemensb@chromium.org
      CC=​jkummerow@chromium.org
      
      Bug: v8:11714
      Change-Id: I67c8679495c55fa51da8243582963649abde660b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878738
      Commit-Queue: Daniel Lehmann <dlehmann@google.com>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74435}
      a0a5aeec
  22. 04 May, 2021 1 commit
    • Andreas Haas's avatar
      [wasm] Change return type of WasmCode::index to int · 78fa1453
      Andreas Haas authored
      WebAssembly.Function and functions of the C-API do not have a function
      index. Their index is kAnonymousFuncIndex = -1. Therefore it is
      necessary to change the return type of WasmCode::index() from uint to
      int.
      
      The changes in WasmFrame::Print produces output like the following:
      
      [9]: CWasmEntryFrame [pc: 0x9d200084091]
      [10]: Anonymous wasm wrapper [pc: 0x101c5975c972]
      [11]: WASM [wasm://wasm/f4bee83a], function #1 ('fibonacci_wasm'), pc=0x101c5975c5dc (+0x7c), pos=123 (+32)
      
      R=jkummerow@chromium.org
      
      Bug: v8:11713
      Change-Id: I1012e92713d64d24ed2a92729dd3c2e4a013b9c0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2871455Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74355}
      78fa1453
  23. 03 May, 2021 2 commits
    • Michael Achenbach's avatar
      Revert "[wasm] Add PKU alloc/free and support counter" · f98f496f
      Michael Achenbach authored
      This reverts commit a4c37558.
      
      Reason for revert: Speculative revert.
      Seems to break all gpu builders, e.g.:
      https://ci.chromium.org/p/v8/builders/ci/Linux%20V8%20FYI%20Release%20(NVIDIA)/14577
      
      See shards for detailed output, e.g.:
      https://chromium-swarm.appspot.com/task?id=534a8fbeaca4df10
      
      Check failed: valid_arguments. V8.WasmMemoryProtectionKeysSupport
      
      Original change's description:
      > [wasm] Add PKU alloc/free and support counter
      >
      > To enforce W^X for the WebAssembly code space, we want to explore using
      > Intel memory protection keys for userspace, also known as MPK, PKEYs, or
      > PKU. Instead of flipping page protection flags with mprotect (which
      > incurs a high syscall overhead; and which switches flags for the whole
      > process), this associates a key with each page once, and then changes
      > the permissions of that key with a fast thread-local register write.
      > That is, this gives both finger-grained permissions (per-thread) and
      > more performance.
      >
      > This CL is starts experimenting with PKUs by
      > (1) trying to allocate a protection key once per {WasmEngine} in x64
      > Linux systems, and
      > (2) adding a counter for recording the sucess/failure of that, to assess
      > the support for PKUs on the target machine.
      >
      > The low-level PKU allocating functions should be moved into base/platform
      > long-term, but are inside wasm/ for this CL.
      >
      > R=​clemensb@chromium.org
      > CC=​​jkummerow@chromium.org
      >
      > Bug: v8:11714
      > Change-Id: Ia4858970ced4d0b84cc8c2651e86dceb532c88a7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850932
      > Commit-Queue: Daniel Lehmann <dlehmann@google.com>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74319}
      
      Bug: v8:11714
      Change-Id: I70349d413ac9092e2f033d138887678bfecaae17
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2868607
      Auto-Submit: Michael Achenbach <machenbach@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#74339}
      f98f496f
    • Daniel Lehmann's avatar
      [wasm] Add PKU alloc/free and support counter · a4c37558
      Daniel Lehmann authored
      To enforce W^X for the WebAssembly code space, we want to explore using
      Intel memory protection keys for userspace, also known as MPK, PKEYs, or
      PKU. Instead of flipping page protection flags with mprotect (which
      incurs a high syscall overhead; and which switches flags for the whole
      process), this associates a key with each page once, and then changes
      the permissions of that key with a fast thread-local register write.
      That is, this gives both finger-grained permissions (per-thread) and
      more performance.
      
      This CL is starts experimenting with PKUs by
      (1) trying to allocate a protection key once per {WasmEngine} in x64
      Linux systems, and
      (2) adding a counter for recording the sucess/failure of that, to assess
      the support for PKUs on the target machine.
      
      The low-level PKU allocating functions should be moved into base/platform
      long-term, but are inside wasm/ for this CL.
      
      R=clemensb@chromium.org
      CC=​jkummerow@chromium.org
      
      Bug: v8:11714
      Change-Id: Ia4858970ced4d0b84cc8c2651e86dceb532c88a7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850932
      Commit-Queue: Daniel Lehmann <dlehmann@google.com>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74319}
      a4c37558
  24. 24 Apr, 2021 1 commit
    • Daniel Lehmann's avatar
      [wasm] Add missing scopes for code modification · eb57c722
      Daniel Lehmann authored
      This is the second CL in a line of two (see crrev.com/c/2835237) to
      bring write-protection to the WebAssembly code space. The previous CL
      changed the page permissions from W^X (only either writable or
      executable can be active, but never both) to write-protection (due to
      concurrent execution in the main thread). However, write-protection
      still did not work, because in several places the code space is
      modified without properly switching it to writable beforehand.
      
      This CL fixes --wasm-write-protect-code-memory such that it can now be
      enabled again (with potentially high overhead due to frequent page
      protection switches). For that, it adds the missing switching to
      writable by adding {NativeModuleModificationScope} objects (similar to
      the already existing {CodeSpaceWriteScope} objects for Apple M1
      hardware).
      
      This CL also fixes a race condition between checking for the current
      writable permission and actually setting the permission, by protecting
      the counter of currently active writers with the same lock as the
      {WasmCodeAllocator} itself. (Before multi-threaded compilation, this
      was not necessary.)
      
      Finally, this CL also changes the {Mutex} protecting the
      {WasmCodeAllocator} to a {RecursiveMutex} because it can be requested
      multiple times in the call hierarchy of the same thread, which would
      cause a deadlock otherwise. Since {TryLock()} of a {RecursiveMutex}
      never fails, this also removes the (now failing) DCHECKs.
      
      R=clemensb@chromium.org
      CC=​​jkummerow@chromium.org
      
      Bug: v8:11663
      Change-Id: I4db27ad0a9348021b0b663dbe88b3432a4d8d6b5
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835238
      Commit-Queue: Daniel Lehmann <dlehmann@google.com>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74163}
      eb57c722
  25. 19 Apr, 2021 2 commits
    • Daniel Lehmann's avatar
      [wasm] Allow execution while modifying code space · 8fffd56f
      Daniel Lehmann authored
      The --wasm-write-protect-code-memory flag previously enforced W^X, that
      is the WebAssembly code space was either writable or executable, but
      never both at the same time. With compilation in background threads
      concurrent to execution in the main thread, this simple scheme is no
      longer viable because the same memory page can indeed be written to and
      executed at the same time. Hence, this flag is currently broken and
      disabled and the code space is always writable AND executable.
      
      As a first step towards more security, we at least want to
      write-protect the code space (when not required writable by compilation
      threads) but at the same time keep it always executable (because of
      concurrent execution in the main thread). That is, we no longer switch
      between RX and RW (W^X), but rather between RX and RWX
      (write-protection only).
      
      This CL starts to change from W^X (which was broken) to
      write-protection only when enabling --wasm-write-protect-code-memory.
      This is the first of two CLs, where the followup CL will fix the
      feature, and this CL merely prepares and cleans up the code. In
      particular, this CL changes the permissions from RW to RWX (due to
      concurrent execution) and renames `WasmCodeAllocator::SetExecutable()`
      to `WasmCodeAllocator::SetWritable()` (and similarly named callers) to
      be consistent with that change. Since the code space is now always
      executable, this CL also removes now unneeded calls to
      `SetExecutable(true)` in tests.
      
      R=clemensb@chromium.org
      CC=​​jkummerow@chromium.org
      
      Bug: v8:11663
      Change-Id: I2065eed6770215892b81daefbddf74a349e783cc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835237Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Daniel Lehmann <dlehmann@google.com>
      Cr-Commit-Position: refs/heads/master@{#74041}
      8fffd56f
    • Clemens Backes's avatar
      [wasm] Merge two related Mutexes into one · 2eefd6a1
      Clemens Backes authored
      This changes the interaction between {NativeModule} and
      {WasmCodeAllocator}. The {WasmCodeAllocator} is a field of
      {NativeModule}, and only called directly by the {NativeModule}. So far,
      there were two mutexes involved, the {allocation_mutex_} in
      {NativeModule}, and {mutex_} in {WasmCodeAllocator}. This caused
      problems with lock order inversion.
      
      This CL thus merges the two mutex, by always locking the mutex in
      {NativeModule} when calling a non-atomic method in {WasmCodeAllocator}.
      This serializes slightly more code, but none of this should be
      performance-critical.
      
      This removes the awkward {OptionalLock} class and adds the "Locked"
      suffix to a few methods to document that those can only be called
      while holding the allocation mutex.
      
      R=jkummerow@chromium.org
      CC=​dlehmann@google.com
      
      Bug: v8:11663
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_gc_stress_dbg_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
      Change-Id: I8895d61fef23a57b218e068532375bac941a5a77
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831477
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74026}
      2eefd6a1
  26. 15 Apr, 2021 1 commit
    • Thibaud Michaud's avatar
      [wasm][x64] Fix OSR shadow stack violation · 06a2c2e0
      Thibaud Michaud authored
      We currently allow OSR (On-Stack Replacement) of arbitrarily deep return
      addresses. This is in direct violation of Intel CET's shadow stack,
      which we plan to enable eventually.
      
      This change works around this by postponing OSR until after we return to
      the old code. The main changes are:
      - Reserve a slot in Liftoff frames to store the OSR target,
      - Skip the return address modification, and instead store the new code
      pointer in the dedicated slot,
      - Upon returning to the old code, check the slot and do an indirect jump
      to the new code if needed.
      
      CET also prevents indirect jumps to arbitrary locations, so the last
      point is also a CET violation. Valid indirect jump targets must be
      marked with the ENDBRANCH instruction, which I will do in a follow-up
      CL.
      
      Bug: v8:11654
      Change-Id: I6925005211aa95d60803b9409e3c07c7c226b25c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826127
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73977}
      06a2c2e0
  27. 09 Apr, 2021 1 commit
    • Michael Achenbach's avatar
      Revert "[wasm] Add CPU time metrics" · b04f6a41
      Michael Achenbach authored
      This reverts commit dcdaf42f.
      
      Reason for revert: This has problems on mac-arm64:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/3591
      
      Original change's description:
      > [wasm] Add CPU time metrics
      >
      > This adds CPU time metrics to the WasmModuleDecoded (except for streaming),
      > WasmModuleCompiled and WasmModuleTieredUp events. This can later be used
      > to provide this information as UKMs or UMAs.
      >
      > Bug: v8:11611
      > Change-Id: I36818f5efbdcae2d3ed6f27c16db21f9d8440d98
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2796952
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73882}
      
      Bug: v8:11611
      Change-Id: I1c82c3e4f19b3a486538fd62665669f6c5b98438
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2818380
      Auto-Submit: Michael Achenbach <machenbach@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73884}
      b04f6a41