Whether or not people who likely have no actual experience in this space dislike what I’m saying about the pointlessness of using wasm for this use case has no bearing on my correctness. Most of them demonstrated they didn’t know the difference between seccomp and seccomp-bpf and there have been no rational counter arguments that hold their weight.

Usually downvotes without rational rebuttals are a sign of the OP’s correctness.

I mention the downvotes because when you find yourself thinking you're right and everyone is wrong usually it's you that's mistaken.

In this case anyone with experience in computer security can tell you multiple layers of defense are always better than one.

Seccomp is great, and I think you actually have a point about it, but it's hard to get right without locking out all system calls entirely - and that's hard to do and still run a program, even a barebones C program.

With higher level languages it's immediately insufficient.

There’s no need for me to guess if I’m wrong or not, prove to me that I’m wrong. Thus far most replies have confused seccomp for seccomp-bpf.

Seccomp locks out every system call except for read, write, exit, and sigreturn. That’s why the extra defense afforded by wasm is superfluous here.

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.