### PART 1 (as the comment was too long for the system here) ###: > The FS sandboxing is actually part of WASI AFAIK it's part of some WASI implementations, a

### PART 1 (as the comment was too long for the system here) ###: > The FS sandboxing is actually part of WASI AFAIK it's part of some WASI implementations, and not a mandatory requirement by WASI. But maybe I'm wrong here. Could you point to some authoritative documents that bakes your claim about WASI? > […] where WASM is essentially just providing a way to run a function from JS with near native speed. Could you explain how you get "near native speed" in a managed VM? No VM overhead on WASM? What did all the other VMs wrong for so many years that everywhere else there are significant overheads and slowdowns compared to native code? Could you point to some benchmarks that bake your claim? > C/C++ works fine. It essentially acts like a bare metal embedded device, but without access to hardware registers. You cant even print to console by default. Could you explain how some random C/C++ program can run in an environment without the possibility to do basically anything? What happens for example when I print to the console form such program? > This does means most of the C standard library won't work, but C itself doesn't care. How does a C program run without C library? I was never talking about the C/C++ languages as such. I said: You can forget to cross compile C/C++. Because I assume that almost no code C/C++ code out there will work in an environment without any possibly to do basically anything. But maybe I'm very wrong here. Could you explain how this works? > There are no system calls either, only whitelisted functions calls statically provided to the WASM code. Ah nice. And those calls are automatically sandboxes, yes? How is the sandbox configured? How does it prevent anything bad form happening? This would require call filters, that inspect the parameters, and then decide what to do on every call, right? If so, what's about the overhead of such a "call firewall"? How does it affect performance? Where do I find the documentation for this sandbox? > The JVM's bytecode design makes it hard to translate C to it, whereas WASM is designed for languages like C with arbitrary pointer arithmetic. WASM just turns point access into memory offsets, while the JVM or CLR assume a Java like language. How is this relevant? If WASM is modeled after the C languages requirements, why are people saying that it would be easily usable for other, high-level languages? Wouldn't that mean that I need to write a VM that runs in a VM? How would such a construct affect performance and resource usage? What additional sandboxing could this bring to the table? Please keep in mind here that the VM in the VM needs to talk to the outside world to fulfill it's std. lib contracts. How does this work? > Browsers have been shipping WASM VMs for years now without disaster, so apparently they do know whats required for sandboxing. But we're not talking about an JS VM embedded WASM VM. We're talking about a standalone WASM VM outside of the JS VM. How does sandboxing work there? How are the WASI calls sandboxed? (See also all the remarks above). Where can I find the documentation for that? > If you can prove otherwise and break out of WASM you could make a lot of money from Google's security bounties or just selling it on the darknet. ;) Could it be that you just again confused "sandboxing" with memory safety? (Which is, once again, a property every "managed" VM runtime provides). > Its been adopted outside browsers by security conscious companies like cloud-flare and fastly to provide sandboxing of user code, etc. Oh, more sandboxing. Could you point to some documentation how this sandboxing works on the technical level? AFAIK they just run the usual containers in HW hypervisor VMs, where you can than place your WASM runtime… So you get in the end sandboxing form the std. hardware based VM. (Because nobody trusts containers for security. And then anyway, in such scenario the workload inside the container is irrelevant). > Memory safety is a crucial piece of sandboxing, though many VMs do provide that. Could you point to any VM that does not? > However most VMs also provide mechanisms to escape the memory sandbox though so they're not good at being sandboxes. How is WASI different here? What's the magic that WASI has, but nobody else? Do you think a sandbox like the one that the JVM just throw away could prevent memory access outside the JVM? How does the provided escape mechanism work actually on the JVM? Is this part of the JVM? Or would it require some "unsafe" access through unofficial APIs which are not part of the platform? Could you explain how this looks like in other popular VMs? I'm not familiar with such. > The other crucial part for sandboxing is control flow. The VM must prevent code from being able to hijack control flow, or to otherwise generate code to escape the sandbox. Could you explain why this does not work reliably on the JVM? (Even there is by standard byte code verification in place, of course.) But please keep in mind that there is no user-level way to generate native code on the fly on the JVM. Only a JIT, which is actually not part of the platform, can do this. So how do I hijack control flow on the JVM (or other popular VMs)? Could you explain this (under the assumption that there are no bugs in the implementation of course, as this would render any VM protections on any platform likely useless obviously). > What most of the hype around WASM is actually about is the ability to provide this sandbox isolation after translating WASM bytecode to native binary code. Even in the face of implementation bugs in the "translator"? How does this magic work? Why do they still add "bumper spaces" around the WASM memory then? Should be strictly unnecessary given the magic property of WASM that the AoT compiler or JIT output is still safe, or not? > Most JVM VMs also do JIT'ing at runtime, but the JVM has some runtime features and assumptions that make statically compiling upfront harder. WASM was designed to enable ahead of time compiling from the outset. That is a key difference between JVM and WASM. How would this work with say Java on WASM? What's the magic here again that makes it hard to AoT compile Java for the the JVM platform but it's easy to compile it AoT to WASM? What do I miss? Could it be that this feature is only relevant in case the language you're compiling is anyway one of the few that are AoT compiled and not run inside a VM by default? But than again, how is WASM the superior VM to run all kinds of languages like advertised (given almost all languages besides a few exceptions are VM languages)? > For example here's a paper from Stanford & UC folks for a static verification engine for checking that binary executables translated from WASM to maintain the sandboxing: https://cseweb.ucsd.edu//~dstefan/pubs/johnson:2021:veriwasm https://cseweb.ucsd.edu//~dstefan/pubs/johnson:2021:veriwasm... Interesting. Is this VeriWasm widely used in industry? Who's using it in production? (One could also ask who verified the verifier implementation, but that's always the question with SW verification; usually you can "just trust" multiple layers of insights. Otherwise SW verification would be useless; which it's not imho!) At least the introduction of the paper answers a few of the previous questions. Let me cite: > WebAssembly (Wasm) is a platform-independent bytecode that offers both good performance and runtime isolation. To implement isolation, the compiler inserts safety checks when it compiles Wasm to native machine code. While this approach is cheap, it also requires trust in the compiler’s correctness—trust that the compiler has inserted each necessary check, correctly formed, in each proper place. Unfortunately, subtle bugs in the Wasm compiler can break—and have broken isolation guarantees. I'm not further commenting on this part. I think the statements stand on their own.