abrown opened PR #7353 from abrown:pku-robust-mapping
to bytecodealliance:main
:
Previously, we assumed that the Wasmtime engine would be able to
allocate keys 1-15 from the OS, in that order. (Recall that Linux
reserves key 0 for itself). While enabling various tests for MPK,
tests inwasmtime_fuzzing::oracles
would fail because Wasmtime could
only start allocating at key 2, e.g.; it turns out that the
diff_v8::smoke
test instantiates V8 which happens to allocate a key
for itself.The reason for the "allocate keys 1-15 in order" assumption was that the
logic for calculating the stripe each key owned was very simple:key - 1
. We needed some way to map each key ID to the stripe ID it is
associated with.With this change, we maintain a little bit more state in order to make
the mapping less brittle.ProtectionKey
stores the "key ID to slice
ID" mapping as an additionalu32
in the struct. This means that,
regardless of what other code in the process allocates MPK keys,
Wasmtime should be able to work fine with the remaining keys it can
allocate.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
abrown requested alexcrichton for a review on PR #7353.
abrown requested wasmtime-core-reviewers for a review on PR #7353.
alexcrichton submitted PR review.
abrown has enabled auto merge for PR #7353.
abrown merged PR #7353.
Last updated: Dec 23 2024 at 12:05 UTC