Re:WebAssembly doesn’t make unsafe languages safe
by AgentME on Sunday November 25, 2018 @10:16PM
(#18530778)
>This is all overwhelmingly worse than in the native case, because we make some effort to run only trustworthy native code, but browsers actively solicit unknown code from known-hostile sources--most particularly, web ads. The existence of safe-ish languages doesn't help, because there is no incentive to deploy them in user-hostile code fragments.
WebAssembly strongly sandboxes WASM modules that are executed, so the situation where an attacker creates and serves a malicious WASM module to the user's browser is one that is handled well.
The article is saying that WASM's protections stop a module from escaping its sandbox, but it doesn't prevent a buggy module from having its own memory get corrupted by its own memory-related bugs common in unsafe languages.
Re:WebAssembly doesn’t make unsafe languages safe
by indolering on Tuesday November 27, 2018 @12:45AM
(#18539769)
WASM was designed to be fast enough to compete with native code and can't do integer overflow checking without serious performance regressions - Rust had to make the same tradeoff.
Furthermore, induction and compiler optimizations can remove the need for such checks. Aren't you solving this at the wrong layer of abstraction?
The second most common source of process corruption, integer overflow, usually ignored in native targets because direct memory corruption is so much worse, is also adopted into WebAssembly wholesale.
This is all overwhelmingly worse than in the native case, because we make some effort to run only trustworthy native code, but browsers actively solicit unknown code from known-hostile sources--most particularly, web ads.
The existence of safe-ish languages doesn't help, because there is no incentive to deploy them in user-hostile code fragments.