Issue 11714 in v8: [wasm] Write-protection of generated code with PKEYs/PKU

516 views
Skip to first unread message

dlehm… via monorail

unread,
Apr 29, 2021, 7:40:07 AM4/29/21
to v8-re...@googlegroups.com
Status: Assigned
Owner: dleh...@google.com
CC: jkum...@chromium.org, ecmzi...@chromium.org, clem...@chromium.org
Components: WebAssembly
HW: x64
OS: Linux
Priority: 2
Type: Task

New issue 11714 by dleh...@google.com: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714

The current (non-optimized) version of write-protection for the WebAssembly generated code space is based on page protection flag switching (e.g., with mprotect). See https://bugs.chromium.org/p/v8/issues/detail?id=11663. This incurs a high overhead between 3x and 10x for compilation (likely due to expensive syscalls when switching the page protection flags).

An alternative would be to use "protection keys for userland" (also known as MPKs, PKEYs, or PKU), a recent feature in Intel server CPUs and newer AMD Ryzen 5xxx CPUs. See https://man7.org/linux/man-pages/man7/pkeys.7.html. There, the protection is thread-local (i.e., gives higher security) and stored in a register (i.e., much cheaper to switch). Conceptually, it is similar to MAP_JIT on Apple M1 hardware, which is already used there because pages are not allowed to be allocated with W+X.

A first prototype implementation for Linux on x64 hardware can make use of pkey_* functions in glibc >= 2.27 to implement this as an alternative to mprotect-based write protection.

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Git Watcher via monorail

unread,
May 3, 2021, 5:58:05 AM5/3/21
to v8-re...@googlegroups.com

Comment #1 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c1

The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c

commit a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c
Author: Daniel Lehmann <dleh...@google.com>
Date: Mon May 03 08:00:36 2021

[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=clem...@chromium.org
CC=​jkum...@chromium.org

Bug: v8:11714
Change-Id: Ia4858970ced4d0b84cc8c2651e86dceb532c88a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850932
Commit-Queue: Daniel Lehmann <dleh...@google.com>
Reviewed-by: Clemens Backes <clem...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74319}

[modify] https://crrev.com/a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c/BUILD.gn
[modify] https://crrev.com/a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c/src/flags/flag-definitions.h
[modify] https://crrev.com/a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c/src/logging/counters-definitions.h
[add] https://crrev.com/a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c/src/wasm/memory-protection-key.cc
[add] https://crrev.com/a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c/src/wasm/memory-protection-key.h
[modify] https://crrev.com/a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c/src/wasm/wasm-code-manager.cc
[modify] https://crrev.com/a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c/src/wasm/wasm-code-manager.h
[modify] https://crrev.com/a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c/src/wasm/wasm-engine.cc

cleme… via monorail

unread,
May 3, 2021, 6:46:43 AM5/3/21
to v8-re...@googlegroups.com
Updates:
Blocking: chromium:1204982

Comment #2 on issue 11714 by clem...@chromium.org: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c2

(No comment was entered for this change.)

Git Watcher via monorail

unread,
May 3, 2021, 1:26:08 PM5/3/21
to v8-re...@googlegroups.com

Comment #3 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c3


The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/1803dcfe087cd3444de693cbc382138775a02da9

commit 1803dcfe087cd3444de693cbc382138775a02da9
Author: Clemens Backes <clem...@chromium.org>
Date: Mon May 03 17:25:49 2021

[v8][wasm] Add histogram for PKU support

This adds a histogram for PKU support, added in V8 in
https://crrev.com/c/2850932.

R=mlip...@chromium.org
CC=​dleh...@google.com, jkum...@chromium.org

Bug: 1204982, v8:11714
Change-Id: I3dfc1b89547dc34c8ae0db38813a59973da7cb50
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2866509
Commit-Queue: Clemens Backes <clem...@chromium.org>
Reviewed-by: Michael Lippautz <mlip...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#878453}

[modify] https://crrev.com/1803dcfe087cd3444de693cbc382138775a02da9/tools/metrics/histograms/histograms_xml/v8/histograms.xml

Git Watcher via monorail

unread,
May 3, 2021, 3:16:09 PM5/3/21
to v8-re...@googlegroups.com

Comment #4 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c4


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/f98f496f9e5e9faea58e1de737d9d46e2248b337

commit f98f496f9e5e9faea58e1de737d9d46e2248b337
Author: Michael Achenbach <mache...@chromium.org>
Date: Mon May 03 19:14:44 2021

Revert "[wasm] Add PKU alloc/free and support counter"

This reverts commit a4c37558d14ed8aa31a0550ffbb3ee202a6e8f0c.

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=​clem...@chromium.org
> CC=​​jkum...@chromium.org
>
> Bug: v8:11714
> Change-Id: Ia4858970ced4d0b84cc8c2651e86dceb532c88a7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850932
> Commit-Queue: Daniel Lehmann <dleh...@google.com>
> Reviewed-by: Clemens Backes <clem...@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 <mache...@chromium.org>
Commit-Queue: Rubber Stamper <rubber-...@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-...@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#74339}

[modify] https://crrev.com/f98f496f9e5e9faea58e1de737d9d46e2248b337/BUILD.gn
[modify] https://crrev.com/f98f496f9e5e9faea58e1de737d9d46e2248b337/src/flags/flag-definitions.h
[modify] https://crrev.com/f98f496f9e5e9faea58e1de737d9d46e2248b337/src/logging/counters-definitions.h
[delete] https://crrev.com/8f68f32fdb0eab287532b63d2113d16bbb459853/src/wasm/memory-protection-key.cc
[delete] https://crrev.com/8f68f32fdb0eab287532b63d2113d16bbb459853/src/wasm/memory-protection-key.h
[modify] https://crrev.com/f98f496f9e5e9faea58e1de737d9d46e2248b337/src/wasm/wasm-code-manager.cc
[modify] https://crrev.com/f98f496f9e5e9faea58e1de737d9d46e2248b337/src/wasm/wasm-code-manager.h
[modify] https://crrev.com/f98f496f9e5e9faea58e1de737d9d46e2248b337/src/wasm/wasm-engine.cc

Git Watcher via monorail

unread,
May 7, 2021, 8:12:05 AM5/7/21
to v8-re...@googlegroups.com

Comment #5 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c5


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/a0a5aeec7b14858b95512f28852f9275693bc32a

commit a0a5aeec7b14858b95512f28852f9275693bc32a
Author: Daniel Lehmann <dleh...@google.com>
Date: Fri May 07 10:00:09 2021

[wasm] Add PKU flag and alloc/free functions


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).
Change-Id: I67c8679495c55fa51da8243582963649abde660b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878738

Commit-Queue: Daniel Lehmann <dleh...@google.com>
Reviewed-by: Clemens Backes <clem...@chromium.org>

Git Watcher via monorail

unread,
May 7, 2021, 12:15:08 PM5/7/21
to v8-re...@googlegroups.com

Comment #6 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c6


The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/0826d17b3d960dd8548980aa5e4e8a01c520d989

commit 0826d17b3d960dd8548980aa5e4e8a01c520d989
Author: Clemens Backes <clem...@chromium.org>
Date: Fri May 07 16:13:59 2021

Add wasm code protection flags

This adds two flags to enable memory protection of code JITed for
WebAssembly. One of them uses memory protection keys which are only
available on 64-bit Linux for now, so we also limit the flag to that
platform.

The flags will be used for manual experimentation and for finching.

R=har...@chromium.org

Bug: 1204982,v8:11714
Change-Id: I8fe32188b8c827f838f66aa2c5fc6e7ef70411ab
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2868385
Reviewed-by: Arthur Sonzogni <arthurs...@chromium.org>
Reviewed-by: Kentaro Hara <har...@chromium.org>
Commit-Queue: Clemens Backes <clem...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#880429}

[modify] https://crrev.com/0826d17b3d960dd8548980aa5e4e8a01c520d989/content/public/common/content_features.cc
[modify] https://crrev.com/0826d17b3d960dd8548980aa5e4e8a01c520d989/content/public/common/content_features.h
[modify] https://crrev.com/0826d17b3d960dd8548980aa5e4e8a01c520d989/content/renderer/render_process_impl.cc
[modify] https://crrev.com/0826d17b3d960dd8548980aa5e4e8a01c520d989/tools/metrics/histograms/enums.xml

cleme… via monorail

unread,
May 10, 2021, 4:41:17 AM5/10/21
to v8-re...@googlegroups.com
Issue 11714: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714

This issue is now blocking issue 1206814.
See https://bugs.chromium.org/p/chromium/issues/detail?id=1206814

Git Watcher via monorail

unread,
May 10, 2021, 11:52:09 AM5/10/21
to v8-re...@googlegroups.com

Comment #8 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c8


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/5f4a9045ac06616e109ceaae23a4eb0d46853599

commit 5f4a9045ac06616e109ceaae23a4eb0d46853599
Author: Daniel Lehmann <dleh...@google.com>
Date: Mon May 10 14:59:54 2021

[wasm] Add PKU support histogram


This is a partial reland of https://crrev.com/c/2850932, which was
reverted because the histogram failed Chromium integration. The V8
histogram added here uses only two values (0 = no support, 1 = support),
but is declared with 3 buckets in order not not fail a DCHECK on
Chromium's side. As soon as https://crrev.com/c/2874651 lands in
Chromium, we can properly declare the histogram here with only 2 buckets,
but for now this is good enough to get early data on PKU support in
the wild.

The other part of the original reverted CL (adding PKU alloc and free
functions, and a V8 flag for PKU) was already landed again in
https://crrev.com/c/2878738


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=clem...@chromium.org
> CC=​jkum...@chromium.org
>
> Bug: v8:11714
> Change-Id: Ia4858970ced4d0b84cc8c2651e86dceb532c88a7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850932
> Commit-Queue: Daniel Lehmann <dleh...@google.com>
> Reviewed-by: Clemens Backes <clem...@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74319}

Bug: v8:11714, chromium:1207318
Change-Id: I1035ac09bd7aa04584fbc5df7a408b96dd270d0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2871451
Reviewed-by: Clemens Backes <clem...@chromium.org>
Commit-Queue: Daniel Lehmann <dleh...@google.com>
Cr-Commit-Position: refs/heads/master@{#74477}

[modify] https://crrev.com/5f4a9045ac06616e109ceaae23a4eb0d46853599/src/logging/counters-definitions.h
[modify] https://crrev.com/5f4a9045ac06616e109ceaae23a4eb0d46853599/src/wasm/wasm-engine.cc

Git Watcher via monorail

unread,
May 11, 2021, 6:58:08 AM5/11/21
to v8-re...@googlegroups.com

Comment #9 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c9


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/7ff863b3ef393b2ee2db32c92a05a9d597556ff4

commit 7ff863b3ef393b2ee2db32c92a05a9d597556ff4
Author: Daniel Lehmann <dleh...@google.com>
Date: Tue May 11 10:01:40 2021

[wasm] Add PKU key permissions functions

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=clem...@chromium.org

Bug: v8:11714
Change-Id: I0da00818f28cf1da195a5149bf11fccf87c5f8ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2882797

Commit-Queue: Daniel Lehmann <dleh...@google.com>
Reviewed-by: Clemens Backes <clem...@chromium.org>

Git Watcher via monorail

unread,
May 11, 2021, 7:44:05 AM5/11/21
to v8-re...@googlegroups.com

Comment #10 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c10


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/826642c7d82079e548c6c0cd37c1984050d3442b

commit 826642c7d82079e548c6c0cd37c1984050d3442b
Author: Daniel Lehmann <dleh...@google.com>
Date: Tue May 11 11:40:50 2021

[wasm] Use PKUs for code space write protection

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=clem...@chromium.org

Bug: v8:11714
Change-Id: I3527906a8d9f776ed44c8d5db52539e78e1c52fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2882800

Commit-Queue: Daniel Lehmann <dleh...@google.com>
Reviewed-by: Clemens Backes <clem...@chromium.org>

Git Watcher via monorail

unread,
May 21, 2021, 1:47:16 PM5/21/21
to v8-re...@googlegroups.com

Comment #12 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c12


The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/bfc9cba4bd654624ee8a94c871d72a53449331a9

commit bfc9cba4bd654624ee8a94c871d72a53449331a9
Author: Clemens Backes <clem...@chromium.org>
Date: Fri May 21 17:46:21 2021

Make wasm code protection via PKU available on ChromeOS

In V8 we do not distinguish between Linux and ChromeOS, but chromium
does. Hence the feature was accidentally only made available on Linux,
and not on ChromeOS. This CL fixes that.

R=har...@chromium.org

Bug: 1204982,v8:11714
Change-Id: I4a29f2ef4e26d438e8709b32cab2006f726931d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2912796
Auto-Submit: Clemens Backes <clem...@chromium.org>
Reviewed-by: Kentaro Hara <har...@chromium.org>
Reviewed-by: Alex Moshchuk <ale...@chromium.org>
Commit-Queue: Alex Moshchuk <ale...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#885553}

[modify] https://crrev.com/bfc9cba4bd654624ee8a94c871d72a53449331a9/content/public/common/content_features.cc
[modify] https://crrev.com/bfc9cba4bd654624ee8a94c871d72a53449331a9/content/public/common/content_features.h
[modify] https://crrev.com/bfc9cba4bd654624ee8a94c871d72a53449331a9/content/renderer/render_process_impl.cc

bo… via monorail

unread,
May 31, 2021, 12:23:56 PM5/31/21
to v8-re...@googlegroups.com

Comment #13 on issue 11714 by bo...@chromium.org: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c13

FYI: I think this broke rr debugging since it doesn't yet support the pkeys syscall. Is there a way to avoid this code path with a command line flag?

dlehm… via monorail

unread,
May 31, 2021, 12:34:40 PM5/31/21
to v8-re...@googlegroups.com

Comment #14 on issue 11714 by dleh...@google.com: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c14

PKUs should be off by default, but you could explicitly disable it explicitly by passing --no-wasm-memory-protection-keys to d8 (or --js-flags="--no-wasm-memory-protection-keys" to Chromium). How/which command line invocation did break exactly?

bo… via monorail

unread,
May 31, 2021, 12:46:40 PM5/31/21
to v8-re...@googlegroups.com

Comment #15 on issue 11714 by bo...@chromium.org: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c15

Interesting, I used:

rr record ./out/ChromeDebug/chrome --single-process

And got rr crashes:

(task 925083 (rec:925083) at time 71761)
-> Assertion `t->regs().syscall_result_signed() == -syscall_state.expect_errno' failed to hold. Expected ENOSYS for 'pkey_alloc' but got result 1 (errno errno(-1)); execution of syscall unsupported by rr

I saw that the flag's default values is false...but I did fix my issue by taking the false branch of FLAG_wasm_memory_protection_keys in each instance in wasm-code-manager.cc. I'll check if the --js-flags works instead.

dlehm… via monorail

unread,
May 31, 2021, 12:51:09 PM5/31/21
to v8-re...@googlegroups.com

Comment #16 on issue 11714 by dleh...@google.com: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c16

If this is an unstable version of Chrome, you could be running (randomly) a finch experiment with this variant enabled. Does it go away with a fresh profile? See also https://bugs.chromium.org/p/chromium/issues/detail?id=1212252

bo… via monorail

unread,
May 31, 2021, 1:20:52 PM5/31/21
to v8-re...@googlegroups.com

Comment #17 on issue 11714 by bo...@chromium.org: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c17

Ah, it's a ToT build but it's full chrome which IIRC does download finch trials after the first run so that would explain it!

--js-flags="--no-wasm-memory-protection-keys" does fix it as well but a fresh profile did not...(though wouldn't help me in this case anyway as I need to let the profile sync for my repro)

Git Watcher via monorail

unread,
Jun 7, 2021, 8:23:15 AM6/7/21
to v8-re...@googlegroups.com

Comment #18 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c18


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/304949b1d31d6af48fd5498dfbb134ad40ef33fe

commit 304949b1d31d6af48fd5498dfbb134ad40ef33fe
Author: Clemens Backes <clem...@chromium.org>
Date: Mon Jun 07 11:33:52 2021

[wasm] Delay taking PKU sample until first module creation

We currently take the sample at the moment the isolate is created. At
that point, the embedder callback for taking samples is not installed
yet. Hence delay taking the sample until the first module is created.
This will only take samples for isolates that actually use wasm, which
will reduce the overall number of samples, but will give a better
picture of PKU support for Wasm.

R=jkum...@chromium.org
CC=dleh...@google.com

Bug: v8:11714
Change-Id: I8a4163961c06076efd6c5dde5751682b53863c2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944429
Reviewed-by: Jakob Kummerow <jkum...@chromium.org>
Commit-Queue: Clemens Backes <clem...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74975}

[modify] https://crrev.com/304949b1d31d6af48fd5498dfbb134ad40ef33fe/src/wasm/wasm-engine.cc

Git Watcher via monorail

unread,
Jun 14, 2021, 8:52:21 AM6/14/21
to v8-re...@googlegroups.com

Comment #19 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c19


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/4fc4efb74e2ac8396f85343d4df7a5dc4275285f

commit 4fc4efb74e2ac8396f85343d4df7a5dc4275285f
Author: Clemens Backes <clem...@chromium.org>
Date: Mon Jun 14 07:55:43 2021

[flags] Stage wasm code protection behind --future

This configuration (PKU with fallback to mprotect) is already finched,
and can hopefully be enabled by default soon. Hence stage it behind
--future to get more test and fuzzer coverage.
Change-Id: I5c38c71582e79e3348e6296cbf175655d00a635c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2959611

Reviewed-by: Jakob Kummerow <jkum...@chromium.org>
Commit-Queue: Clemens Backes <clem...@chromium.org>

Git Watcher via monorail

unread,
Jun 18, 2021, 3:59:06 AM6/18/21
to v8-re...@googlegroups.com

Comment #20 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c20


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/d0cfa6aab527195bcc02cf13bfac78ea030849b3

commit d0cfa6aab527195bcc02cf13bfac78ea030849b3
Author: Daniel Lehmann <dleh...@google.com>
Date: Thu Jun 17 15:47:04 2021

[wasm] Align different write protection scopes

Currently, we have two different classes for switching the WebAssembly
generated code space to writable (e.g., before patching jump tables, or
when adding or removing code): `CodeSpaceWriteScope` (with the macro
`CODE_SPACE_WRITE_SCOPE`) and `NativeModuleModificationScope`.
The former was introduced for Apple Silicon ARM64 hardware ("Apple M1"),
which uses `MAP_JIT` + `pthread_jit_write_protect_np()` to change memory
permissions. The latter uses either Intel PKU (aka. memory protection
keys) to switch permissions (fast and thread-local, like on M1), and
alternatively `mprotect()`, on systems that do not have PKU support.

Since both classes serve the same purpose just with different
implementations on different platforms, we want to merge them in
follow-up CLs. As a first step, here we align all uses of
`CODE_SPACE_WRITE_SCOPE` with existing `NativeModuleModificationScope`s.
The two had diverged due to optimization work, where we moved
`NativeModuleModificationScope`s around (pulling them out of loops and
across function boundaries) to lower the amount of mprotect switches.

This should have none, or at best a very small positive performance
impact on Apple M1, since we now also switch less often (even though
switching should be very cheap). In terms of security, this in theory
makes the code space writable for longer time spans, but this is
probably not a large effect because
(1) we often moved the scope outside of loops, where it was open for
every iteration anyway, or
(2) in some cases a CODE_SPACE_WRITE_SCOPE was open somewhere on the
call stack already.

R=jkum...@chromium.org
CC=clem...@chromium.org

Bug: v8:11714
Change-Id: Id8744429e1183e118ab5e078750d294a99c9dce0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968946
Reviewed-by: Jakob Kummerow <jkum...@chromium.org>
Commit-Queue: Daniel Lehmann <dleh...@google.com>
Cr-Commit-Position: refs/heads/master@{#75230}

[modify] https://crrev.com/d0cfa6aab527195bcc02cf13bfac78ea030849b3/src/wasm/wasm-code-manager.cc

Git Watcher via monorail

unread,
Jun 21, 2021, 8:23:08 AM6/21/21
to v8-re...@googlegroups.com

Comment #21 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c21


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/2ef8f917ff73788f59753bb0342ca9b3ea131d58

commit 2ef8f917ff73788f59753bb0342ca9b3ea131d58
Author: Daniel Lehmann <dleh...@google.com>
Date: Fri Jun 18 11:42:32 2021

[wasm] Move NativeModuleModificationScope impl

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.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Change-Id: I1aabce26f2033430523a7a3a0a4864e7267bee21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972803
Reviewed-by: Clemens Backes <clem...@chromium.org>
Commit-Queue: Daniel Lehmann <dleh...@google.com>
Cr-Commit-Position: refs/heads/master@{#75267}

[modify] https://crrev.com/2ef8f917ff73788f59753bb0342ca9b3ea131d58/BUILD.bazel
[modify] https://crrev.com/2ef8f917ff73788f59753bb0342ca9b3ea131d58/BUILD.gn
[add] https://crrev.com/2ef8f917ff73788f59753bb0342ca9b3ea131d58/src/wasm/code-space-access.cc
[modify] https://crrev.com/2ef8f917ff73788f59753bb0342ca9b3ea131d58/src/wasm/code-space-access.h
[modify] https://crrev.com/2ef8f917ff73788f59753bb0342ca9b3ea131d58/src/wasm/module-compiler.cc
[modify] https://crrev.com/2ef8f917ff73788f59753bb0342ca9b3ea131d58/src/wasm/module-instantiate.cc
[modify] https://crrev.com/2ef8f917ff73788f59753bb0342ca9b3ea131d58/src/wasm/wasm-code-manager.cc
[modify] https://crrev.com/2ef8f917ff73788f59753bb0342ca9b3ea131d58/src/wasm/wasm-code-manager.h

Git Watcher via monorail

unread,
Jun 21, 2021, 10:14:12 AM6/21/21
to v8-re...@googlegroups.com

Comment #22 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c22


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/8a3c48817bf484259d9ea22fcd70062356aa7e1b

commit 8a3c48817bf484259d9ea22fcd70062356aa7e1b
Author: Daniel Lehmann <dleh...@google.com>
Date: Mon Jun 21 12:27:53 2021

[wasm] Merge code space write scope implementations

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=clem...@chromium.org
CC=jkum...@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/+/2972911

Reviewed-by: Clemens Backes <clem...@chromium.org>
Commit-Queue: Daniel Lehmann <dleh...@google.com>

Git Watcher via monorail

unread,
Jun 23, 2021, 11:28:07 AM6/23/21
to v8-re...@googlegroups.com

Comment #23 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c23


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/ac6546469dccb2364816e46078b671040f080161

commit ac6546469dccb2364816e46078b671040f080161
Author: Clemens Backes <clem...@chromium.org>
Date: Wed Jun 23 14:27:25 2021

[wasm] Remove WasmInstructionBuffer

{WasmInstructionBuffer} was basically a wrapper around {AssemblerBuffer}
which remembered the last {AssemblerBuffer} on {Grow()}. Since the
{Assembler} itself already keeps track of the latest {AssemblerBuffer},
this functionality is mostly redundant. All we need instead is a method
to retrieve the {AssemblerBuffer} from the {Assembler}.

This CL thus removes {WasmInstructionBuffer} and instead adds
{AssemblerBase::ReleaseBuffer}.

R=jkum...@chromium.org, msle...@chromium.org
CC=dleh...@google.com

Bug: v8:11714
Change-Id: Id07945b67992802a6177bf09e5f5c5be08f657b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982013
Commit-Queue: Clemens Backes <clem...@chromium.org>
Reviewed-by: Maya Lekova <msle...@chromium.org>
Reviewed-by: Jakob Kummerow <jkum...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75336}

[modify] https://crrev.com/ac6546469dccb2364816e46078b671040f080161/src/codegen/assembler.cc
[modify] https://crrev.com/ac6546469dccb2364816e46078b671040f080161/src/codegen/assembler.h
[modify] https://crrev.com/ac6546469dccb2364816e46078b671040f080161/src/compiler/backend/code-generator.cc
[modify] https://crrev.com/ac6546469dccb2364816e46078b671040f080161/src/compiler/backend/code-generator.h
[modify] https://crrev.com/ac6546469dccb2364816e46078b671040f080161/src/compiler/pipeline.cc
[modify] https://crrev.com/ac6546469dccb2364816e46078b671040f080161/src/wasm/baseline/liftoff-compiler.cc
[modify] https://crrev.com/ac6546469dccb2364816e46078b671040f080161/src/wasm/function-compiler.cc
[modify] https://crrev.com/ac6546469dccb2364816e46078b671040f080161/src/wasm/function-compiler.h
[modify] https://crrev.com/ac6546469dccb2364816e46078b671040f080161/src/wasm/wasm-code-manager.cc

Git Watcher via monorail

unread,
Jun 23, 2021, 11:48:09 AM6/23/21
to v8-re...@googlegroups.com

Comment #24 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c24


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/f8182a8e8adef9ba5fb97f4503852367453e6dd5

commit f8182a8e8adef9ba5fb97f4503852367453e6dd5
Author: Maya Lekova <msle...@chromium.org>
Date: Wed Jun 23 15:46:04 2021

Revert "[wasm] Remove WasmInstructionBuffer"

This reverts commit ac6546469dccb2364816e46078b671040f080161.

Reason for revert: Breaks ASAN no-inline - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Clusterfuzz%20Linux64%20ASAN%20no%20inline%20-%20release%20builder/22909/overview

Original change's description:

> [wasm] Remove WasmInstructionBuffer
>
> {WasmInstructionBuffer} was basically a wrapper around {AssemblerBuffer}
> which remembered the last {AssemblerBuffer} on {Grow()}. Since the
> {Assembler} itself already keeps track of the latest {AssemblerBuffer},
> this functionality is mostly redundant. All we need instead is a method
> to retrieve the {AssemblerBuffer} from the {Assembler}.
>
> This CL thus removes {WasmInstructionBuffer} and instead adds
> {AssemblerBase::ReleaseBuffer}.
>
> R=​jkum...@chromium.org, msle...@chromium.org
> CC=​dleh...@google.com
>
> Bug: v8:11714
> Change-Id: Id07945b67992802a6177bf09e5f5c5be08f657b0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982013
> Commit-Queue: Clemens Backes <clem...@chromium.org>
> Reviewed-by: Maya Lekova <msle...@chromium.org>
> Reviewed-by: Jakob Kummerow <jkum...@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75336}

Bug: v8:11714
Change-Id: Iff32952f712ab2f0f9a16d91906d0135c084f4df

No-Presubmit: true
No-Tree-Checks: true
No-Try: true

Commit-Queue: Rubber Stamper <rubber-...@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-...@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#75337}

[modify] https://crrev.com/f8182a8e8adef9ba5fb97f4503852367453e6dd5/src/codegen/assembler.cc
[modify] https://crrev.com/f8182a8e8adef9ba5fb97f4503852367453e6dd5/src/codegen/assembler.h
[modify] https://crrev.com/f8182a8e8adef9ba5fb97f4503852367453e6dd5/src/compiler/backend/code-generator.cc
[modify] https://crrev.com/f8182a8e8adef9ba5fb97f4503852367453e6dd5/src/compiler/backend/code-generator.h
[modify] https://crrev.com/f8182a8e8adef9ba5fb97f4503852367453e6dd5/src/compiler/pipeline.cc
[modify] https://crrev.com/f8182a8e8adef9ba5fb97f4503852367453e6dd5/src/wasm/baseline/liftoff-compiler.cc
[modify] https://crrev.com/f8182a8e8adef9ba5fb97f4503852367453e6dd5/src/wasm/function-compiler.cc
[modify] https://crrev.com/f8182a8e8adef9ba5fb97f4503852367453e6dd5/src/wasm/function-compiler.h
[modify] https://crrev.com/f8182a8e8adef9ba5fb97f4503852367453e6dd5/src/wasm/wasm-code-manager.cc

Git Watcher via monorail

unread,
Jun 23, 2021, 12:40:05 PM6/23/21
to v8-re...@googlegroups.com

Comment #25 on issue 11714 by Git Watcher: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c25


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/c581e790dc9ff2489bcf5d5be3bf44ba47769c72

commit c581e790dc9ff2489bcf5d5be3bf44ba47769c72
Author: Clemens Backes <clem...@chromium.org>
Date: Wed Jun 23 16:00:58 2021

Reland "[wasm] Remove WasmInstructionBuffer"

This is a reland of ac6546469dccb2364816e46078b671040f080161.
Two constants defined in {AssemblerBase} were not defined anywhere,
which is fixed now.


Original change's description:
> [wasm] Remove WasmInstructionBuffer
>
> {WasmInstructionBuffer} was basically a wrapper around {AssemblerBuffer}
> which remembered the last {AssemblerBuffer} on {Grow()}. Since the
> {Assembler} itself already keeps track of the latest {AssemblerBuffer},
> this functionality is mostly redundant. All we need instead is a method
> to retrieve the {AssemblerBuffer} from the {Assembler}.
>
> This CL thus removes {WasmInstructionBuffer} and instead adds
> {AssemblerBase::ReleaseBuffer}.
>
> R=jkum...@chromium.org, msle...@chromium.org
> CC=dleh...@google.com
>
> Bug: v8:11714
> Change-Id: Id07945b67992802a6177bf09e5f5c5be08f657b0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982013
> Commit-Queue: Clemens Backes <clem...@chromium.org>
> Reviewed-by: Maya Lekova <msle...@chromium.org>
> Reviewed-by: Jakob Kummerow <jkum...@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75336}

Bug: v8:11714
Change-Id: I8797de1a7a78a93aaef936e46bfd1e73ec2cc9d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982015

Reviewed-by: Maya Lekova <msle...@chromium.org>
Reviewed-by: Jakob Kummerow <jkum...@chromium.org>
Commit-Queue: Clemens Backes <clem...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75338}

[modify] https://crrev.com/c581e790dc9ff2489bcf5d5be3bf44ba47769c72/src/codegen/assembler.cc
[modify] https://crrev.com/c581e790dc9ff2489bcf5d5be3bf44ba47769c72/src/codegen/assembler.h
[modify] https://crrev.com/c581e790dc9ff2489bcf5d5be3bf44ba47769c72/src/compiler/backend/code-generator.cc
[modify] https://crrev.com/c581e790dc9ff2489bcf5d5be3bf44ba47769c72/src/compiler/backend/code-generator.h
[modify] https://crrev.com/c581e790dc9ff2489bcf5d5be3bf44ba47769c72/src/compiler/pipeline.cc
[modify] https://crrev.com/c581e790dc9ff2489bcf5d5be3bf44ba47769c72/src/wasm/baseline/liftoff-compiler.cc
[modify] https://crrev.com/c581e790dc9ff2489bcf5d5be3bf44ba47769c72/src/wasm/function-compiler.cc
[modify] https://crrev.com/c581e790dc9ff2489bcf5d5be3bf44ba47769c72/src/wasm/function-compiler.h
[modify] https://crrev.com/c581e790dc9ff2489bcf5d5be3bf44ba47769c72/src/wasm/wasm-code-manager.cc

dlehm… via monorail

unread,
Jul 1, 2021, 8:40:47 AM7/1/21
to v8-re...@googlegroups.com
Updates:
Status: Fixed

Comment #26 on issue 11714 by dleh...@google.com: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c26

A prototype using Intel PKU is now implemented behind the --wasm-memory-protection-keys flag in V8, and available in Chrome dev/canary. The code is also integrated with a fallback implementation that uses mprotect-based write protection if PKU support is not available (see https://bugs.chromium.org/p/v8/issues/detail?id=11663).

da… via monorail

unread,
Aug 2, 2022, 9:58:00 AM8/2/22
to v8-re...@googlegroups.com

Comment #27 on issue 11714 by da...@davidmanouchehri.com: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c27

Something I ran into, is that the current logic for detecting memory protection keys support does *not* check CPUID registers. This is an issue if you are masking CPUID with the expectation of hiding pkey support, as neither V8 nor glibc care about it.

The fix is pretty simple as already described in https://bugs.chromium.org/p/v8/issues/detail?id=11714#c14.

--js-flags="--no-wasm-memory-protection-keys"

cleme… via monorail

unread,
Aug 2, 2022, 12:28:26 PM8/2/22
to v8-re...@googlegroups.com

Comment #28 on issue 11714 by clem...@chromium.org: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c28

Interesting. Shouldn't the kernel check that, and just not return a key on pkey_alloc?
In which way does it fail currently?

da… via monorail

unread,
Aug 2, 2022, 3:01:48 PM8/2/22
to v8-re...@googlegroups.com

Comment #29 on issue 11714 by da...@davidmanouchehri.com: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c29

The issue is that we/I end up having pkey_alloc syscalls in debugging traces, which you sometimes want to avoid due to kernel bugs.

i.e. there is a kernel bug that broke ptrace writing to PKRU on 5.14+ kernels. https://patchwork.kernel.org/project/kvm/patch/20220731050342.56513-1-kh...@kylehuey.com/

If a flag is supposed to disable a feature, I don't believe we should go against the user's expectations and go around probing for it. We're also just burning CPU cycles for no reason. https://chromium-review.googlesource.com/c/v8/v8/+/3806059

cleme… via monorail

unread,
Aug 3, 2022, 9:42:46 AM8/3/22
to v8-re...@googlegroups.com

Comment #30 on issue 11714 by clem...@chromium.org: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c30

I am not convinced yet that potential kernel bugs are a good enough reason to do anything here. As noted on https://crrev.com/c/3806059, please open a new issue where we can discuss this.

da… via monorail

unread,
Aug 3, 2022, 10:07:13 AM8/3/22
to v8-re...@googlegroups.com

Comment #31 on issue 11714 by da...@davidmanouchehri.com: [wasm] Write-protection of generated code with PKEYs/PKU
https://bugs.chromium.org/p/v8/issues/detail?id=11714#c31

Sure, but I think fixing what has already been merged in is a good enough reason.

https://bugs.chromium.org/p/v8/issues/detail?id=13143
Reply all
Reply to author
Forward
0 new messages