You're totally ignoring the parts I called you out on, which I'm tempted to view as a tacit admission you see your position there as indefensible.

The trouble is you can't run much in that environment - not even mmap or sbrk to allocate heap memory. It's basically embedded C without even malloc. In reality WASM is a more practical target because many high level languages can compile to it. Or you end up needing seccomp-bpf and now the burden is on you to provide enough functionality to run something without also providing so much to allow a sandbox escape.

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.