4 ms·
> But WASM is already sandboxed Sandboxing only secures the boundary between the WASM interpreter and the embedding application (typically the browser). You ca
by rng_civ 6y ago
> But WASM is already sandboxed
Sandboxing only secures the boundary between the WASM interpreter and the embedding application (typically the browser). You can still perform significant exploits within the sandbox. See [0]
IIRC, low-level languages need to maintain a shadow stack in the heap because WASM has no native support for stack variable pointers and without ASLR, we're inching dangerously close to classic buffer overflow attacks. Rust still buys you safety in that regard.
[0] https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...
- millstone 6y agoSorry but that's baloney. Web developers are not choosing Rust/WASM because of security concerns with C++/WASM. The whole point of WASM is to enable untrusted code. Instead I believe they are choosing Rust/WASM because of the Rust ecosystem: familiar package management, tutorials, other resources.
- pas 6y ago> whole point of WASM is to enable untrusted code. ... ? The web is already full of untrusted JS. WASM is for performance. The added extra security is just the cherry on top.