4 ms·

I don't have a lot of knowledge in this area, but using WASM for forcing code to be safe seems bizarre. Why aren't there just compiler flags that can enforce th

I don't have a lot of knowledge in this area, but using WASM for forcing code to be safe seems bizarre. Why aren't there just compiler flags that can enforce the same restrictions they want?

gostsamo 5y ago
This looks more like using the compilation to wasm and back to automatically rewrite the code of entire components in a manner that makes them safer.
7373737373 5y ago
Why is it bizarre? The Wasm function interface seems perfect for sandboxing code. It's a "whitelist" system, the contained process can only call external functions that have been explicitly attached, perfect for implementing the capability security paradigm and progressively hollowing out the attack surface by separating functionality into several instances.
- Deukhoofd 5y ago
  Requiring compilation to WASM to then translate it back to C and compile it again might be a bit strange. Clang obviously already has the tools to do the WASM sanitizing, it might be really cool to have a way to directly enforce those rules outside of WASM.
  - bilkow 5y ago
    As I understand it, clang doesn't have the tools to sanitize WASM. It just emits WASM, which, malicious or benevolent, can't access memory outside its designated memory regions. It's wasm2c job to ensure that the C generated enforces the WASM memory rules, so I'd say the one sanitizing the code is not clang but wasm2c.
azakai 5y ago
For technical reasons adding compiler flags to do that is fairly hard. You'd need to handle a lot of things like compiling to the sandboxed format, system library support, the FFI to normal code, etc. It would be possible to do all that, but wasm has already done it - so compiling to wasm as an intermediary step is the most practical solution. (See also https://news.ycombinator.com/item?id=29460766 https://news.ycombinator.com/item?id=29460766)
the_duke 5y ago
Webassembly is much more restricted than regular machine code. It's a stack machine with a limited set of operations, no direct control over the stack/control flow and restricted access to memory. It's way easier to compile this limited set of operations to assembly (or C) that is guaranteed to not do things it shouldn't.
IshKebab 5y ago
You definitely could do that. It would just be a ton of work and nobody has done it.
- deian 5y ago
  It is doable, but it's hard to make it fast on all platform. See the SegmentZero32 description in <https://cseweb.ucsd.edu/~dstefan/pubs/kolosick:2022:isolation.pdf https://cseweb.ucsd.edu/~dstefan/pubs/kolosick:2022:isolatio...> for an example prototype.
bholley 5y ago
Beyond the reasons others have mentioned, another key issue is that this isn't a transparent transformation. The sandboxed code can only access memory within a restricted subregion, which often requires some small code changes on both sides of the boundary (for example, copying input data into that memory region so that sandboxed code can operate on it). So implementing this in the compiler would entail some fairly involved handshaking between the code and the compiler beyond the normal scope of C/C++. Doing this in a library instead — and leaning on a well-understood and well-studied execution model — makes everything a bit more natural to work with.
Tobu 5y ago
NaCL (native client) sort of did this, but through an entirely separate toolchain. It's not an easy task.
masklinn 5y ago
> Why aren't there just compiler flags that can enforce the same restrictions they want? Because they want to compile arbitrary code in order to sandbox it. The alternative is something like eBPF, but that imposes a limited subset of the source language, which would be unlikely to work with something like a video decoder.

I don't have a lot of knowledge in this area, but using WASM for forcing code to be safe seems bizarre. Why aren't there just compiler flags that can enforce the same restrictions they want?

gostsamo 5y ago

This looks more like using the compilation to wasm and back to automatically rewrite the code of entire components in a manner that makes them safer.

7373737373 5y ago

Why is it bizarre? The Wasm function interface seems perfect for sandboxing code. It's a "whitelist" system, the contained process can only call external functions that have been explicitly attached, perfect for implementing the capability security paradigm and progressively hollowing out the attack surface by separating functionality into several instances.

Deukhoofd 5y ago
Requiring compilation to WASM to then translate it back to C and compile it again might be a bit strange. Clang obviously already has the tools to do the WASM sanitizing, it might be really cool to have a way to directly enforce those rules outside of WASM.
- bilkow 5y ago
  As I understand it, clang doesn't have the tools to sanitize WASM. It just emits WASM, which, malicious or benevolent, can't access memory outside its designated memory regions. It's wasm2c job to ensure that the C generated enforces the WASM memory rules, so I'd say the one sanitizing the code is not clang but wasm2c.

azakai 5y ago

For technical reasons adding compiler flags to do that is fairly hard. You'd need to handle a lot of things like compiling to the sandboxed format, system library support, the FFI to normal code, etc. It would be possible to do all that, but wasm has already done it - so compiling to wasm as an intermediary step is the most practical solution. (See also https://news.ycombinator.com/item?id=29460766 https://news.ycombinator.com/item?id=29460766)

the_duke 5y ago

Webassembly is much more restricted than regular machine code. It's a stack machine with a limited set of operations, no direct control over the stack/control flow and restricted access to memory. It's way easier to compile this limited set of operations to assembly (or C) that is guaranteed to not do things it shouldn't.

IshKebab 5y ago

You definitely could do that. It would just be a ton of work and nobody has done it.

deian 5y ago
It is doable, but it's hard to make it fast on all platform. See the SegmentZero32 description in <https://cseweb.ucsd.edu/~dstefan/pubs/kolosick:2022:isolation.pdf https://cseweb.ucsd.edu/~dstefan/pubs/kolosick:2022:isolatio...> for an example prototype.

bholley 5y ago

Beyond the reasons others have mentioned, another key issue is that this isn't a transparent transformation. The sandboxed code can only access memory within a restricted subregion, which often requires some small code changes on both sides of the boundary (for example, copying input data into that memory region so that sandboxed code can operate on it). So implementing this in the compiler would entail some fairly involved handshaking between the code and the compiler beyond the normal scope of C/C++. Doing this in a library instead — and leaning on a well-understood and well-studied execution model — makes everything a bit more natural to work with.

Tobu 5y ago

NaCL (native client) sort of did this, but through an entirely separate toolchain. It's not an easy task.

masklinn 5y ago

> Why aren't there just compiler flags that can enforce the same restrictions they want? Because they want to compile arbitrary code in order to sandbox it. The alternative is something like eBPF, but that imposes a limited subset of the source language, which would be unlikely to work with something like a video decoder.