Open abrown opened 9 months ago
cc: @alexcrichton
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)
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
(data ...)
section to a WebAssembly modulecat /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):/memfd:wasm-memory-image
with key 0 (e.g., 7ffef532c000-7ffef532d000)Versions and Environment
Wasmtime version or commit:
main
Operating system: Linux Architecture: x64Extra Info
One option here is to pass through an
Option<ProtectionKey>
to theMemoryImageSlot::instantiate
function. Other suggestions?