cranelift

rust jit wasm webassembly runtime wasi cranelift sandbox wasmtime

Nick Fitzgerald 2e48babf23 cranelift-wasm: Add a bounds-checking optimization for dynamic memories and guard pages (#6031 ) * cranelift-wasm: Add a bounds-checking optimization for dynamic memories and guard pages This is a new special case for when we know that there are enough guard pages to cover the memory access's offset and access size. The precise should-we-trap condition is index + offset + access_size > bound However, if we instead check only the partial condition index > bound then the most out of bounds that the access can be, while that partial check still succeeds, is `offset + access_size`. However, when we have a guard region that is at least as large as `offset + access_size`, we can rely on the virtual memory subsystem handling these out-of-bounds errors at runtime. Therefore, the partial `index > bound` check is sufficient for this heap configuration. Additionally, this has the advantage that a series of Wasm loads that use the same dynamic index operand but different static offset immediates -- which is a common code pattern when accessing multiple fields in the same struct that is in linear memory -- will all emit the same `index > bound` check, which we can GVN. * cranelift: Add WAT tests for accessing dynamic memories with the same index but different offsets The bounds check comparison is GVN'd but we still branch on values we should know will always be true if we get this far in the code. This is actual `br_if`s in the non-Spectre code and `select_spectre_guard`s that we should know will always go a certain way if we have Spectre mitigations enabled. Improving the non-Spectre case is pretty straightforward: walk the dominator tree and remember which values we've already branched on at this point, and therefore we can simplify any further conditional branches on those same values into direct jumps. Improving the Spectre case requires something that is morally the same, but has a few snags: * We don't have actual `br_if`s to determine whether the bounds checking condition succeeded or not. We need to instead reason about dominating `select_spectre_guard; {load, store}` instruction pairs. * We have to be SUPER careful about reasoning "through" `select_spectre_guard`s. Our general rule is never to do that, since it could break the speculative execution sandboxing that the instruction is designed for.		2 years ago
..
src	cranelift-wasm: Add a bounds-checking optimization for dynamic memories and guard pages (#6031)	2 years ago
Cargo.toml	Update dependencies (#5513)	2 years ago
LICENSE	Initial reorg.	5 years ago
build.rs	Merge pull request from GHSA-wh6w-3828-g9qf	2 years ago