1. 13 May, 2022 1 commit
  2. 28 Jan, 2022 1 commit
  3. 20 Dec, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Initialize memory protection key permissions · d7aaa6d7
      Clemens Backes authored
      Initialize the (thread-local) memory protection key permissions for any
      isolate that joins the wasm engine. Otherwise it can happen that an
      isolate gets Wasm code from the cache without ever compiling anything
      (hence without ever changing memory protection key permissions), and
      then it would not be allowed to access (read or execute) the code.
      
      I tested this change manually on a PKU-enabled devices. The new test
      crashed before the fix, and completes successfully afterwards.
      
      R=ahaas@chromium.org
      
      Bug: v8:11974, chromium:1280451
      Change-Id: I90dded8b4fdaa8cf34b44107291d3f525ce16335
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3347563Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78413}
      d7aaa6d7
  4. 21 Sep, 2021 1 commit
  5. 13 Jul, 2021 3 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
  6. 11 May, 2021 1 commit
    • Daniel Lehmann's avatar
      [wasm] Add PKU key permissions functions · 7ff863b3
      Daniel Lehmann authored
      This is the first CL in a line of two to finish PKU-based WebAssembly
      code space write protection. This CL adds two low-level PKU functions,
      which are essentially wrapping the functionality in glibc's
      {pkey_mprotect()} and {pkey_set()}).
      
      The added functionality is in
      (1) {SetPermissionsAndMemoryProtectionKey()}: Associate a memory
      protection key with a page (simultaneously with setting the page's
      regular permssions). This is as costly as a regular {mprotect()}.
      This call itself does not restrict permissions besides the regular page
      permissions.
      (2) {SetPermissionsForMemoryProtectionKey()}: Set permissions for the
      key itself (now associated with a page). This can be either "all data
      access disabled" (i.e., no read or write, but execution is allowed) or
      "write access disabled" (which we use for code space write protection).
      The permissions are added on top of the page's regular permissions. This
      operation is cheap (in the order of 20 cycles) since it is roughly a
      thread-local register read, some bit-masking, and register write.
      See the second CL (based on this one) for how those two functions will
      be used.
      
      A note on compatability and security implications: Because the functions
      which we use here were only added in glibc 2.27, and since glibc is
      dynamically linked, we check at runtime (with {dlsym()}) whether
      {pkey_*()} functions are available. However, calling functions via a
      pointer coming from {dlsym()} is not supported by CFI so far, which is
      why we disable indirect call checking for the added functions.
      Potentially, the functions could hence be used as an indirect call
      gadget in a ROP attack. On the other hand, they are only compiled in
      currently only on Linux on x64, and disabling CFI indirect call checking
      is also done in other places already.
      
      R=clemensb@chromium.org
      
      Bug: v8:11714
      Change-Id: I0da00818f28cf1da195a5149bf11fccf87c5f8ea
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2882797
      Commit-Queue: Daniel Lehmann <dlehmann@google.com>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74498}
      7ff863b3
  7. 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
  8. 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