Hacker News Reader

Comment by azakai | Hacker News Reader

There is that risk, yes. For wasm2c to be correct it must emit C code without undefined behavior. As best we know it does that properly today, and we've tested and fuzzed it quite a lot, but whenever you use an optimizing C compiler on the output there is no 100% guarantee.

View on HN

The host application is still C, and the final compilation of the mix of C and sanitized C still relies on the optimizer to be fast, so it might be possible for the untrusted library to reveal UB in the rest of the application. I can see how the whole approach (wasm + taint) would make compromise of the sanitized bits through crafted data harder, but I'm not sure it does enough for guarding against a supply chain compromise of the library.

And I see the safe languages section[1] in the WasmBoxC post; that looks like it would address most of the remaining UB risk, but Firefox will take some time getting there.

[1]: https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html...

There's no guarantee even without optimization. Some optimizations exploit UB, but not all "unexpected" code generation in the presence of UB is due to optimization.

Take signed int overflow on addition. On some platforms ADD wraps, on others it traps. Depending on target CPU you'll get very different behavior even for non-optimizing compilers that just emit an ADD instruction!

WASM is just another target, with its own behavior.

Reply on news.ycombinator.com