Why updating to wasmer 4 is safe for gear

[grishasobol]

Summary

Presently gear-lazy-pages is not safe solution in rust paradigm. We have double mutability to wasm executor memory and to wasm globals. This happens because we need to change memory and globals inside signal handler, so memory and globals cannot be passed to lazy-pages logic thru arguments. Also it cannot be passed using global variables, because wasm executors captures this memory and global storages during execution.

But for wasmer 4 executor we can be almost sure, that it's safe to use such double mutability in gear-lazy-pages. To understand why we have to consider several statements:

1. During wasm code execution linear memory buffer can be accessed by wasm load/store instructions only.
2. Each wasm load/store instruction is compiled into batch of native operations, which contains only one load/store operation which accesses the linear memory buffer.
3. Before native load/store operation, which access memory buffer, store: wasmer::Store is in correct state and it's in state which has been right before load/store wasm instruction execution. So, additionally for us this means that globals and memory is not changed since last wasm instruction execution.

We should also wait for an answer from wasmer to check that wasmer guaranties that all memory operations are atomic: wasmerio/wasmer#4596. But supposing that wasmer guaranties that, we can give the following reasoning.

Looking at wasmer vm traphandlers.rs we can see that in case of out of bounds load/store the execution of compiled code is stoped and executor returns from code call function thru some handler function:
https://github.com/wasmerio/wasmer/blob/47ce81114e8e68fc190867f5c15181407f36668d/lib/vm/src/trap/traphandlers.rs#L848-L857

        // Set up the register state for exception return to force the
        // coroutine to return to its caller with UnwindReason::WasmTrap.
        let unwind = UnwindReason::WasmTrap {
            backtrace,
            signal_trap,
            pc,
        };
        let regs = self
            .coro_trap_handler
            .setup_trap_handler(move || Err(unwind));

setup_trap_handler force to exit coroutine execution after returning from signal handler:

    /// Sets up the stack and register state so that once the trap handler
    /// returns, the interrupted coroutine will execute the given function and
    /// then exit the coroutine with the result as a `CoroutineResult::Return`.
    ///
    /// This function works by setting up the coroutine stack for a call to a
    /// special handler function. The returned `TrapHandlerRegs` indicate which
    /// registers the trap handler must update in the interrupted register
    /// context so that control is properly passed to this handler function.

So, as we can see execution is ended in that cases without any store: wasmer::Store recovering. So, we can be sure now that store is in correct state before each native load/store operations execution, and this state is equal to the state which had been right before this load/store wasm instruction execution. In other case execution of load/store is not atomic in wasmer in case a trap appears.

The same can be said about second statement (see above), if wasm load/store compiles into two and more native load/store operations, then can be situation that first load/store is executed ok and second throws out of bounds trap. So, after stoping execution memory won't be in correct state.

The most difficult is first statement. We cannot guaranty that during execution compiled code won't access the linear memory buffer for self purposes. Wasmer can guaranty that these load/store operations is not out of bounds, so we cannot say that store: wasmer::Store is in correct state before these instructions execution. But we suppose that accessing wasm linear memory is not allowed in wasmer outside of wasm load/store instruction execution context.

In conclusion, if all three of above statements are correct we can be sure that it's safe to access globals and memory inside signal handler, because it's guarantied that store is in correct state and this state is equal to one which must be before load/store instruction execution.

Fuzzing

To be more sure that it's safe we can make a fuzzer. This fuzzer have to run different random wasm codes on two different executors (for example wasmer and wasmi). Also during execution signals must appear and change globals and memory inside store. The execution supposed to be correct if both executor shows equal store state after wasm code execution.