bytecodealliance
mpk: memory image slots protection undoes any MPK protection
While adding a test to check that the PKRU bits are properly switched out when each async fiber is suspended, I discovered that memory images are undoing the MPK protection applied to the memory pool. The fix is relatively simple: re-apply the MPK protection. But how we do so matters, since the memory image logic and MPK logic are completely separate at the moment.
Test Case
Initial draft at this branch; some manual tweaking required.
Steps to Reproduce
- add a
(data ...)section to a WebAssembly module - instantiate a pool-allocated, MPK-enabled instance
- observe the memory mappings, e.g., (
cat /proc/$(pidof all-657fb8d34994dd9d)/smaps)
Expected Results
All of the single-page (64kB) slot memory is protected with the same MPK key.
Actual Results
Because the MPK protection is applied when the memory pool is instantiated, each instantiation of a new Wasm module containing image data will replace the MPK protection with generic key 0 protection when MemoryImageSlot::instantiate is called. When instantiating a single-page memory I discovered that the slot was split up with different keys instead of all the same key (e.g., key 1 used here):
- a 4kB read-write mapping for
/memfd:wasm-memory-imagewith key 0 (e.g., 7ffef532c000-7ffef532d000) - a 60kB read-write mapping with key 1 (e.g., 7ffef532d000-7ffef533c000)
- a 216208kB no-access mapping with key 1 (e.g., 7ffef533c000-7fff02660000) — this is the guard region
Versions and Environment
Wasmtime version or commit: main
Operating system: Linux
Architecture: x64
Extra Info
One option here is to pass through an Option<ProtectionKey> to the MemoryImageSlot::instantiate function. Other suggestions?
To confirm, the problem here is that when a new mapping for a memory image is installed in the virtual address space that overwrites the pkey mapping previously configured? And the fix is to pkey_mprotect again? (want to make sure I understand first)
