4 ms·
There is a way to sandbox native code without forking to a new process, and it looks like this https://hacks.mozilla.org/2020/02/securing-firefox-with-webassem
by nextaccountic 2y ago
There is a way to sandbox native code without forking to a new process, and it looks like this
https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
Firefox employs processes for sandboxing but for small components they are not worth the overhead. For those they employed this curious idea: first compile the potentially unsafe code to wasm (any other VM would work), then compile the wasm code to C (using the wasm2c tool). Then use this new C source normally in your program.
All UB in the original code becomes logical bugs in the wasm, that can output incorrect values but not corrupt memory or do things that UB can do. Firefox does this to encapsulate C code, but it can be done with Rust too
- dmitrygr 2y agoYou can skip all this nonsense with -fsanitize=undefined
- Georgelemental 2y agoNot foolproof, doesn’t catch everything.
- cyberax 2y agoIt won't do anything for data races, for example.
- rcxdude 2y agoThe sanitize tools are not intended to be hardening tools, just debugging/testing tools. For instance, they may introduce their own vulnerabilities.
- deleted 2y ago[deleted]
- panstromek 2y agoThat's actually a pretty clever idea, I never realized you can that. Thanks for sharing.
- int_19h 2y agoNote that the reason why this works for sandboxing is that wasm code gets its own linear memory that is bounds-checked. Meaning that the generated C code will contain those checks as well, with the corresponding performance implications.