cranelift

rust jit wasm webassembly runtime wasi cranelift sandbox wasmtime

Andrew Brown 03a14ac64f mpk: optimize layout of protected stripes, again (#7622 ) * mpk: optimize layout of protected stripes, again This is another attempt at #7603, attempting reduce the slab layout sizes of MPK-protected stripes. While experimenting with the limits of MPK-protected memory pools, @alexcrichton and I discovered that the current slab layout calculations were too conservative. This meant that the memory pool could not pack in as many memories as it should have been able: we were expecting, but not seeing, ~15x more memory slots over non-MPK memory pools. This change brings together several fixes: - it more aggressively divides up the stripes (as in `b212152`) - it eliminates an extra stripe (as in `8813a30`) - it replaces some uses of `checked_` with `saturating_` (as in `fb22a20`) - it improves some documentation - and, crucially, it reports back a larger value for `memory_and_guard_size` The failures observed with #7603 when run with MPK (`WASMTIME_TEST_FORCE_MPK=1 cargo test`) were due to `Store::wasm_fault` not being able to identify which memory an OOB address belonged to. This is because the `MemoryPool` was underreporting the size of the region in which OOB accesses would fault. The correct value is provided by the new `SlabLayout::bytes_to_next_stripe_slot`: any OOB access within that larger region must fault because (1) the other stripes have different protection keys and (2) a `Store` can only use one protection key. We also use (2) to guarantee that `Store::wasm_fault` will be able to calculate the Wasm address from the raw address. This change also provides a new `traps` test that will reproduce the failures from #7603; if we observe `SIGABRT` from that test, it will be a regression. * fix: make test x86-specific	11 months ago
..
memory_pool.txt	mpk: optimize layout of protected stripes, again (#7622)	11 months ago

mpk: optimize layout of protected stripes, again (#7622 )

* mpk: optimize layout of protected stripes, again

This is another attempt at #7603, attempting reduce the slab layout
sizes of MPK-protected stripes. While experimenting with the limits of
MPK-protected memory pools, @alexcrichton and I discovered that the
current slab layout calculations were too conservative. This meant that
the memory pool could not pack in as many memories as it should have
been able: we were expecting, but not seeing, ~15x more memory slots
over non-MPK memory pools.

This change brings together several fixes:
- it more aggressively divides up the stripes (as in b212152)
- it eliminates an extra stripe (as in 8813a30)
- it replaces some uses of `checked_*` with `saturating_*` (as in
  fb22a20)
- it improves some documentation
- and, crucially, it reports back a larger value for
  `memory_and_guard_size`

The failures observed with #7603 when run with MPK
(`WASMTIME_TEST_FORCE_MPK=1 cargo test`) were due to `Store::wasm_fault`
not being able to identify which memory an OOB address belonged to.
This is because the `MemoryPool` was underreporting the size of the
region in which OOB accesses would fault. The correct value is provided
by the new `SlabLayout::bytes_to_next_stripe_slot`: any OOB access
within that larger region must fault because (1) the other stripes have
different protection keys and (2) a `Store` can only use one protection
key. We also use (2) to guarantee that `Store::wasm_fault` will be able
to calculate the Wasm address from the raw address.

This change also provides a new `traps` test that will reproduce the
failures from #7603; if we observe `SIGABRT` from that test, it will be
a regression.

* fix: make test x86-specific

11 months ago

memory_pool.txt mpk: optimize layout of protected stripes, again (#7622) 11 months ago