On Linux you can block off syscalls by number these days. If you only want to expose read and write on some pre-prepared file descriptors you can do that. This

On Linux you can block off syscalls by number these days. If you only want to expose read and write on some pre-prepared file descriptors you can do that. This leads to the question of what security is being added by the bytecode layer. You could argue that you're insulated from CPU errata, but cloud and hosting vendors have been selling raw CPU access for decades without real issue beyond side channel attacks (patched, also affects you even with WASM). WASM came out of the web and is needed/wanted by the web folks because they can't rely entirely on operating system kernel sandboxing (Windows is dubious, macOS is powerful but private/undocumented API), and because they don't like the idea of implicitly incorporating every possible device's CPU ISA into the HTML5 spec. Neither issue applies on Linux servers where nothing is a formal spec anyway and the Linux sandboxing facilities are powerful and open. JIT/interpretation can only slow things down over using native code, so "fast startup" is probably being confounded by the fact that WASM programs tend to be written in C++ or Rust.