Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mpk: protect memory with PROT_NONE #7363

Merged
merged 1 commit into from
Oct 25, 2023

Conversation

abrown
Copy link
Contributor

@abrown abrown commented Oct 25, 2023

This change fixes a bug with ProtectionKey::protect: previously it initialized each stripe with read and write permissions (i.e., pkey_mprotect(..., PROT_READ | PROT_WRITE) under the mistaken assumption that these permissions were MPK-specific, "what MPK permissions will we be allowed to set in the PKRU for these regions in the future?". This assumption is incorrect: the regions were immediately made accessible for reading and writing. The fix is to initially protect the regions with PROT_NONE and allow Wasmtime's memory.grow implementation to mark pages with mprotect(..., PROT_READ | PROT_WRITE) as usual. Whether a store can access a slice is still determined by the CPU state set in mpk::allow.

This change fixes a bug with `ProtectionKey::protect`: previously it
initialized each stripe with read and write permissions (i.e.,
`pkey_mprotect(..., PROT_READ | PROT_WRITE)` under the mistaken
assumption that these permissions were MPK-specific, "what MPK
permissions will we be allowed to set in the PKRU for these regions in
the future?". This assumption is incorrect: the regions were immediately
made accessible for reading and writing. The fix is to initially protect
the regions with `PROT_NONE` and allow Wasmtime's `memory.grow`
implementation to mark pages with `mprotect(..., PROT_READ |
PROT_WRITE)` as usual. Whether a store can access a slice is still
determined by the CPU state set in `mpk::allow`.
@abrown abrown requested a review from a team as a code owner October 25, 2023 17:55
@abrown abrown requested review from pchickey and removed request for a team October 25, 2023 17:55
@alexcrichton alexcrichton requested review from alexcrichton and removed request for pchickey October 25, 2023 18:35
Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Is it possible to have a test in this regard? For example if mpk is enabled does that mean that guard pages were accidentally read/write?

@abrown
Copy link
Contributor Author

abrown commented Oct 25, 2023

Yes, I'm working on a test to push soon. The spec tests caught this accidental read/write once I was able to actually run them.

@abrown abrown added this pull request to the merge queue Oct 25, 2023
Merged via the queue into bytecodealliance:main with commit d58f526 Oct 25, 2023
18 checks passed
@abrown abrown deleted the pku-prot-none branch October 25, 2023 20:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants