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.

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)

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.

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.

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.

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.

> 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.

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

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

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:isolatio...> for an example prototype.

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.