Are you serious? You just allocate a large section of virtual memory before entering seccomp mode. This is not hard. I have used seccomp in production myself.

Not to mention sandboxed wasm is similarly restrictive and you need third-party library support to operate in that “embedded” environment. You don’t just get a normal runtime environment for free. Wasm simply gets you memory “bounds checks” but it’s not necessary if the isolate owns the entire process, as in the seccomp model.

Are you serious? You want to ask partners to write embedded C programs using a pre allocated virtual memory range?

It's obvious why they went for WASM instead.

My point was exactly that you don’t necessarily write your code for an embedded environment in the seccomp model. You provide code in a dynamic library format and the normal dynamic linker links the necessary calls (e.g. malloc) at runtime, exactly as a wasm would provide that environment (via WASI or whatever). Since those calls are all only implemented in terms of write,read,exit,and sigreturn you are guaranteed a high level of security.

Wasm is no different in this regard. You don’t get libc for free with wasm. The only thing you get with a wasm format is memory bounds checking but again that isn’t necessary in the seccomp model.

The big difference is the tooling gives you that for free with WASM. You can even run Go programs in WASM. You don't get that with seccomp.