- 13 May, 2022 1 commit
-
-
Clemens Backes authored
Now that we require C++17 support, we can just use the standard static_assert without message, instead of our STATIC_ASSERT macro. R=leszeks@chromium.org Bug: v8:12425 Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80524}
-
- 28 Jan, 2022 1 commit
-
-
Clemens Backes authored
This extracts all {dlsym} calls to a single function which is called once during initialization. R=jkummerow@chromium.org Bug: v8:11974 Change-Id: I068f180e26b92d72e3e1e0ba7c6232c760f202e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3417439Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#78831}
-
- 20 Dec, 2021 1 commit
-
-
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:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#78413}
-
- 21 Sep, 2021 1 commit
-
-
Clemens Backes authored
This adds a few DCHECKs to ensure that the process-wide memory protection key is not writable (per thread) in a few strategic places: - Before switching it to writable (which implicitly checks the initial state), - when entering compiled code, and - in the explicit unit test. R=jkummerow@chromium.org CC=mpdenton@chromium.org Bug: v8:11974 Change-Id: I6037f599afe9009d5e48794eb382eb1979f3ce9f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3165060Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#76953}
-
- 13 Jul, 2021 3 commits
-
-
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:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75707}
-
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}
-
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:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#75699}
-
- 11 May, 2021 1 commit
-
-
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:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74498}
-
- 07 May, 2021 1 commit
-
-
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:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74435}
-
- 03 May, 2021 2 commits
-
-
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}
-
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:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74319}
-