The core implementation idea behind wasm sandboxing is that you can compile C/C++ into wasm code, and then you can compile that wasm code into native code for the machine your program actually runs on. These steps are similar to what you’d do to run C/C++ applications in the browser, but we’re performing the wasm to native code translation ahead of time, when Firefox itself is built.
It's a middle ground between sandboxing with subprocesses (which adds all the overhead of IPC) and switching to a fully memory-safe language (Rust, JS, etc.)
If I were writing a sandboxing or instrumentation tool, operating on WASM would be much simpler than dealing with the quirks of assembly, syscalls, or some higher-level IR.
Comments
At that point, what's the purpose of using WASM at all?
You can keep the sandbox intact after AOT.
https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
It's a middle ground between sandboxing with subprocesses (which adds all the overhead of IPC) and switching to a fully memory-safe language (Rust, JS, etc.)
Control Flow Integrity, https://en.wikipedia.org/wiki/Control-flow_integrity
If I were writing a sandboxing or instrumentation tool, operating on WASM would be much simpler than dealing with the quirks of assembly, syscalls, or some higher-level IR.