File Location(s)

sandbox/host

Proposal

Update wasmi executor to 0.30.

The main problem is latest versions of main-stream executors (wasmi, wasmer, wasmtime) implement WASM store using only Rust borrow semantics and no synchronization primitives. As a result, we cannot simply clone required structures elsewhere.

It is the problem because we have lazy pages concept that requires access to WASM globals during WASM function invocation, when accessing protected memory pages. Pseudocode:

let store = Store::new(...);
func.call(&mut store, ...);

// inside WASM function call
fn call(...) {
	// ...some WASM instructions

	memory.write 123 at 0xCAFE
	// let's think 0xCAFE address belongs to protected memory page, so:
    // 1. MMU sees protected memory and causes interruption to OS
	// 2. We set signal handler earlier, so OS jumps to `signal_handler()`
	// 3. After handler is done, OS jumps back to `memory.write` and it will be successful now

	// ..execution continues
}

// when interruption occurs, lazy-pages signal handler is in work
fn signal_handler() {
    let store = ???; // how to access mutable reference again, if `func.call` holds it?
	global.set(&mut store, 333);
    memory.unprotect 0xCAFE // unprotect page which address belongs to
}

Possible solutions:

• There was the first try in refactor(sandbox): Update WASMI in gear-sandbox #2931 with Allow to modify globals without store wasmi#3. Wrap globals into synchronization primitive. This approach will be required for the future wasmer update, which is harder to implement because wasmer is more complex.
• Suggested by @gshep. Mutable pointer to store. Very dangerous, very unpredictable because it means we have 2 mutable references or multialiasing, which is UB.
• Suggested by @grishasobol. Implement callbacks on every memory access at executor's side. It requires maintaining patches as in the first solution.
• Perhaps the executor authors know how to deal with the new design? Store access during signal wasmerio/wasmer#4118