Stream: git-wasmtime

Topic: wasmtime / PR #14076 mpk: restore protection keys after m...


view this post on Zulip Wasmtime GitHub notifications bot (Aug 04 2026 at 00:37):

jlb6740 opened PR #14076 from jlb6740:mpk-issue-13982-fix to bytecodealliance:main:

A fresh mmap associates the pages it replaces with the default protection key 0, and key 0 is accessible from every stripe (host code needs it). MemoryImageSlot maps over pkey-colored pool slots in three places, so any module with a (data ...) segment silently lost its key. Because MPK striping deliberately shrinks the guard regions between slots, a neighboring instance could then read and write that memory for real. Note that mprotect preserves the key, so only mmap sites are affected.

Fix this by re-applying the key with pkey_mprotect after each mmap: add ProtectionKey::reprotect, give MemoryImageSlot the key its stripe was colored with, and call the new reapply_pkey helper after map_at, remap_as_zeros_at, and erase_existing_mapping.

Tables, stacks, and GC heaps are never pkey-colored, and decommit uses madvise(MADV_DONTNEED) which preserves VMA flags, so MemoryImageSlot was the only exposure.

Cost: one extra syscall per mmap, and instantiate only mmaps when a slot is handed a different image than it already holds. Measured over 1000 instantiations, a module repeatedly instantiated into its affine slot adds 8 calls total (one per slot, at first use) and is in the noise end-to-end. A pool thrashing between more modules than it has slots takes 2 extra calls per instantiation, ~+43% on instantiation. With MPK disabled ProtectionKey is uninhabited and this all compiles away.

Fixes #13982
Fixes #7942

<!--
Please make sure you include the following information:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

view this post on Zulip Wasmtime GitHub notifications bot (Aug 04 2026 at 01:10):

jlb6740 updated PR #14076.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 04 2026 at 03:48):

github-actions[bot] added the label wasmtime:api on PR #14076.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 05 2026 at 00:57):

jlb6740 has marked PR #14076 as ready for review.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 05 2026 at 00:57):

jlb6740 requested dicej for a review on PR #14076.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 05 2026 at 00:57):

jlb6740 requested wasmtime-core-reviewers for a review on PR #14076.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 06 2026 at 16:17):

dicej commented on PR #14076:

@alexcrichton Would you mind taking a look at this when you have a chance? This is outside my area of expertise.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 07 2026 at 17:35):

:thumbs_up: alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 07 2026 at 17:35):

alexcrichton added PR #14076 mpk: restore protection keys after mmap'ing memory images to the merge queue.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 07 2026 at 18:01):

:check: alexcrichton merged PR #14076.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 07 2026 at 18:01):

alexcrichton removed PR #14076 mpk: restore protection keys after mmap'ing memory images from the merge queue.


Last updated: Aug 30 2026 at 10:08 UTC