And what of all these languages that compile to JS, like Typescript, Reason, Kotlin, et al? Is JS a sound "IR" between the frontend and WebAssembly? Or would it be better to compile things directly to WebAssembly?
Imagine being able to run a complex C dependency (with a high risk of buffer overflows) risk-free because it's running in a WASM sandbox?
Or building features that allow users to provide their own executable code (for plugins and extensions and other customization features) where they code is executed in a sandbox with strictly controlled CPU/memory/network and API access control.
With something like CPython or the JVM, you’re attempting to sandbox something that was designed to be able to run arbitrary code, and was never designed to be restrained in this way, and if you miss even one thing, it’s completely broken. https://web.mit.edu/jesstess/www/pytennessee_sandbox.pdf is a good summary of what a problem this is, and why it’s basically impossible to secure that way: you’re plugging a huge number of leaks in a massive surface area, and you will not get it watertight—to say nothing of the fact that lots of software depends on those leaks existing (for perfectly benign reasons). And every C extension that you load increases the vulnerable surface area (e.g. https://www.hebergementwebs.com/news/escape-a-python-sandbox... describes using a numpy bug to escape a CPython sandbox). You just can’t run a successful sandbox inside CPython or the JVM; instead, you must run the language inside a sandbox—and even that is often troublesome.
WebAssembly, on the other hand, is isolated. There are no leaks, and the surface area is tiny, because it was designed that way. It can’t do anything directly save computation on what it’s given; it depends on the runtime to grant it access to any external resources. This completely guards against all direct attacks, leaving only side-channel attacks, which are a vastly less dangerous class in general, and easier to guard against once you know about them, because the runtime controls execution.
-it's extremely secure, tested for many years, etc...
-it's different than other VMs, almost no types or functions, the VM cannot access outside memory, only call functions supplied by the host (or write to stdout, again supplied by the host.)
-It loads fast, runs fast. Browser JavaScript has been very optimized.
-unrelated to the browser, but many languages can be compiled to WASM
What you see in this project is the WASI interface that provides the normal libc functions like fopen(), allowing WASM to act like a normal binary. But you can run WASM with other sets of functions, or none and the host can do all the moving of bytes.
Cloudflare, Netlify and others are trying to figure out how to host WASM for cloud functions because it's perfect for their systems: small, fast and safe.
Wasm on the server using WASI (which nowadays is probably either wasmtime or wasmer) doesn't have anything to do with Javascript.
Actually, wasm on the browser doesn't have anything to do with javascript either! This is actually unfortunate, because wasm in the browser can't natively interface with JS's GC yet [0].
On the other hand, I think a great strength of wasm is that wasm isn't tied to a single memory management system: if it forced a GC on you, it would also need to dictate the memory layout, and would need to determine how this GC gets run, all this would add unnecessary overheard and inflexibility when compiling low-level languages. Or when compiling any language that don't quite conform to the memory management model, different languages want to manage memory differently. This is a pain in the JVM and wasm fixed that.
Another strength is vendor neutrality. All major browsers embraced wasm, and it's got multiple implementations in the server as well. There isn't really a dominant implementation that others must conform, and wasm tools are interoperable between implementations. There are also embedded implementations (I know of wamr and wasm3).
On a darker note, I'm sad to see see one WASI runtime bashing another [1]; I wish the competition was more cordial, or at least, more professional.
[0] see the issues in this repo https://github.com/WebAssembly/gc
[1] https://wasmer.io/wasmer-vs-wasmtime - makes outlandish claims and uses benchmarks without clearly specifying what is being benchmarked (ideally it would link to a Github repo)
And only if that would be the case the use of WASM would be an advantage. For general extensibility we had Java servlets, Lua modules, PHP modules, etc in webservers for decades.
Maybe it’s interesting for source code obfuscation purposes or in order to allow migration of server logic between different languages. But even that was possible before - and I don’t think the Market need was huge.
Java servlets, Lua and PHP modules cannot be run securely, and there are vulnerabilities for all of them.
The thing is, the JVM was designed with the explicit intention of making it possible to run untrusted code safely: how do we know we got it right this time? The problem really isn't the VM, it's the APIs and authorization model for access to the underlying system's features.
Also because the API surface area that server side apps need is really just not big, JVM had a lot of problems because it tried to do too much.
If all you think about is whether things are safe versus unsafe, everything is “fake security” and you’ll never come up with defense in depth.
The sandbox should make buffer overflows someone else’s problem, or at least an acceptable risk. You seem to be denying one of the most important reasons we have them?
A consequence, though, if the code is genuinely untrusted, is that you have to revalidate any requests after they’re sent to the system outside the sandbox. (Just as we can’t trust client-side validation on the server.) It seems like that would be duplicate work.
(An exception might be when an authenticated user is modifying their own files and you don’t care what they do.)
That doesn't help if you need to run other people's code.
Yeah, I wonder how it would look like. /s
Like any bytecode (including jvm's), it comes at a performance penalty over bare asm. I personally don't anticipate it will replicate jvm's success as being a runtime when there is no reason for a runtime to exist - since it shouldn't be much harder to compile wasm (and languages that compile to wasm) to native asm ahead of time. On the other hand I wouldn't have predicted jvm's success either.
In places where you want a runtime though, like in shared computation models where it gives you security/performance advantages, it makes perfect sense. It looks like it's probably going to succeed there to me.
Compiling X -> JS -> Wasm doesn't make much sense. Not only is wasm a language with cleaner semantics to compile to, but JS doesn't actually really fit wasm semantics particularly well. In fact, while I could have missed something, I'm not aware of any good JS->wasm compilers. The closest I can think of is https://www.assemblyscript.org/ - and it's not 100% JS compatible.
A runtime like wasmer-python [0] is only 1.5MB.
There have been plenty of similar stacks, JVM is just one among many.
2 - it's the only things that also run on the web
3 - it's probably going to be ubiquitous because of that, meaning it will be a great platform to target by default
4 - it could potentially mean any platform run any code from any other one without having to deal with wrappers: you would write a lib in go or rust, and then run it as is in python
Sandboxing is of little help when external events can cause internal memory corruption that change module's expected outcomes.
It is as good as typical OS process.
WASM has some interesting properties, like sandboxing, a small set of instructions you can fit in your head and some fairly high level constructs (for a compilation target).
However I don't quite know what other benefits it provides. It certainly cannot compete with the JVM/CLR on many fronts. And I don't see quite a lot of use-cases yet that cannot be covered with just integrating V8. Happy to learn more about that (actual rationales).
Yes, see: https://bytecodealliance.org/articles/1-year-update
> Or would it be better to compile things directly to WebAssembly?
It'd be even better to roll out one's own Lambda@Edge: https://krustlet.dev/
Source: https://twitter.com/solomonstre/status/1111004913222324225?l...