WASM's sandboxing as implemented in practice is different from JITs. It works by allocating a 4GB region of virtual memory and treating the base address as NULL. Pointers in WASM are 32 bit so they are unable to point outside the region.
The big win is the runtime doesn't need to check pointers for validity. However there are some downsides relative to native code:
1. Can't address more than 4GB of memory
2. Can't be efficiently implemented on 32 bit systems
3. Can't share memory between WASM modules
4. NULL dereferences don't trap (I think)
I would not be surprised if future CPUs had hardware support for this stuff, e.g. load/stores with a mask to confine the pointers.
The other way it ensures isolation is by separating code and data. All executable code lives in a separate address space that is not accessible from within wasm. Call stack is also a separate area, making it impossible to muck around or even look at the return pointer. Function pointers are opaque - they can live in global or local variables and in table entries (which are also completely separate from memory), but not in memory; when one needs such a pointer as part of the data structure (e.g. vtables), an index into a table is used instead.
