If Core Wasm took security seriously, the memory access opcodes for arrays would be bound checked like on MSIL and TIMI, instead of "as long as it is inside of a linear memory segment we're good" approach.
Arguably, memory safety inside the WASM heap is the job of the compiler, it's often possible to omit runtime range- and null-checks with the control-flow knowledge the compiler has access to which would be tricky to transmit down to the bytecode level (and even then it would only benefit a handful of languages that have builtin concepts for "ranges" and "nullability".
If you need more fine-grained isolation, split your code into different WASM instances.
"Arguably, memory safety inside the UNIX process heap is the job of the compiler, ...."
See what I did there?
And then we are back at the root problem of goverments having to step in, and hardware vendors coming up with hardware memory tagging, because that isn't scaling.
> "Arguably, memory safety inside the UNIX process heap is the job of the compiler, ...."
In my mind there's nothing controversial about this statement at all.
If memory corruption inside the sandbox allows to manipulate anything outside the sandbox, then the sandbox is broken. It's as simple as that, and it doesn't matter whether it's the WASM heap or a process heap.
And if there is no guarantee that the sandbox is on a safe state, whose execution doesn't translate into nasty side effects, like return true instead of false on a credential check, due to internal memory corruption, then it is equally broken.
It becomes the same approach as attacking OS processes via their public OS IPC end points.
