It's a way of running WASM code, which can be anything from anywhere, safely. It only gets access to the folders you let it access as a capability. It gets no access to anything else.
So, no matter how evil, or confused, the program is, you aren't risking your entire system. It's the best part of capability based security.
This is an advertisement, not an answer. Wasmtime is a way of running WASM bytecode, which is a little virtual machine (of the Java, rather than QEMU, type). You can run your WASM code on it and because it runs in the runtime you can, at least in theory, sandbox it by controlling what it has access to. If your runtime and the computer it is running on is perfect (which happens to be an unsolved problem, sadly) then you can run anything inside of the runtime and it can only do what you give it access to. In practice the runtime is not perfect and bugs will let very malicious code escape, but overall the security of running things in such a runtime is usually much better than doing so directly, at the cost of some performance.
Java Security Manager has a rich history of leaking capabilities to code that should not have them. As has practically every capability-based system ever.
Capabilities are no Silver Bullet. They work exceptionally well with small teams, but like memory leaks, reachability decisions tend not to scale to very large teams, and people start exposing information for a feature without being able to trace the consequences of having done so.
I could potentially see someone recasting this story as a parable against shared state, but I'm not convinced it's the sole cause or that you could have one without the other. I think it is true that they share a problem space, but that's neither a particularly brave nor illuminating statement.
Do you have a favorite alternative to the capability model that you feel is superior? I somewhat casually follow these discussions and I'm always looking for new ideas (or old ones that actually work better in some cases).
The weird thing about the security APIs in Java is that it contained both capabilities and an ACL model with a sort of hierarchy to it, both of inheritance and being able to run a function in a scope. I got to use it for real on a project and if you overlooked the extreme clunkiness of trying to capture a set of rights as configuration, it wasn't that bad.
So I could say, do that again but with a better way to define rules programatically instead of a priori. Multi-tenant, multiple roles, or a Cartesian product of the two sort of demand a little bit of bespoke rules engine work.
Except Java has support for shared memory between threads, whereas WASM is single-threaded with message passing. Don't expect e.g. to implement a high-performance multi-threaded database in WASM anytime soon.
"Write once run anywere" heard that many times. No sandbox is going to give you safety. Spectre and Meltdown are great examples of that. It is the matter of time and popularity. Cryptojacking and malware is already the problem[0].
I would add that it can be useful to have isolated runtimes even if you're not a PaaS. Say you need to parse an obscure file format that can be uploaded from untrusted users (and nowadays, that's all users). You've got some ancient C or C++ source code for the parser, but it hasn't been vetted for security or denial-of-service issues. Compile it to WASM, run it in an isolated runtime, and you can be confident that it won't be able to escape its sandbox while also minimizing startup times and using significantly fewer resources than needing a container for each invocation.
> You've got some ancient C or C++ source code for the parser, but it hasn't been vetted for security or denial-of-service issues. Compile it to WASM, run it in an isolated runtime, and you can be confident that it won't be able to escape its sandbox
Personally I’d want to be very cautious about this. It’s probably more secure than just running this untrusted binary directly on a server full of user uploaded content but I don’t know what level of confidence is should have in wasmtime not having any container escapes possible.
Yes. Consider that Spectre allowed reading browser memory that wasn’t exposed to JavaScript from within the JS sandbox. Something similar probably would have been possible with WASM, if Spectre hadn’t already been found and mitigated.
I love capability based limits like this (and in Deno), but they’re not a panacea.
> For those of you who have been around for the better part of the past couple of decades, you may notice this looks very similar to RFC3875, better known as CGI (The Common Gateway Interface). While our example here certainly does not conform to the specification, you can imagine how this can be extended to turn the stdin of a basic 'command line' application into a full-blown http handler.
Anything that wants to run arbitrary, possibly untrusted user-provided code, with good speed and minimal startup time. The big use cases are AWS Lambda-like things (whether that's serving web requests or reacting to event queues), as well as plugin systems for software.
I wrote a (very surface level) comparison on this last year[1]. If you already have V8 in your environment, it's probably worth using V8, but if you just want to load a wasm interpreter into some Rust code, wasmtime is a much nicer interface to work with and more lightweight.
The Bytecode Alliance is a nonprofit group with members from all over the industry working to provide what is ostensibly a reference implementation of a WebAssembly runtime w/ full WASI support. Wasmtime is their implementation.
They are far from the only implementation, though. You can find links to other runtimes in other comments here already.
I have the same questions still, after reading all the material and also researching between papers and conference talks.
My takeaway so far is: it’s a faster, more flexible, and lighter JVM-like thing.
As someone who had written Java Applets from back in the day on the UI side, and written plenty of server side and seen a lot of FaaS successes and failures (more the latter than the former), all the features and use cases map 1:1 - so not really new use cases. Just way better design and implementation (which may make architectures actually end-user usable), w/o money-ed interest.
The article shows startup time from enter to output being very, very fast.
Having rust, go, c, c++, being able to be transpiled to wasm byte code is already more flexible than jvm. Why isn’t there a popular C front end to jvm? -> there’s the flex. Also wasm runs in browser w/o loading applets.
Worry about bloat when the project is more mature; there’s no bloat right now and worth exploring.
Latest Javas can run hello world in about 50msec or less. If you AOT compile the app it can do so a bit faster than an app written in C, believe it or not. This is not really a competitive advantage for wasmtime.
Actually, wasm is less flexible than the JVM because with GraalVM/Truffle you can run:
1. WASM
2. LLVM bitcode
both on the JVM, alongside all the other languages it can do like Python, Ruby, Clojure, JavaScript, Kotlin, Smalltalk, R etc. Therefore you can run Rust, C and C++ on the JVM. Don't think you can run Go, but this is still way more languages on the JVM than WASM.
You ask why there's no popular C frontend for the JVM. It's because nobody really cares about running C on a VM except for people targeting Chrome/Safari. You can do it with GraalVM and it has some uses for running C language extensions to scripting languages, but otherwise is a bit of a curiousity. Usually if you want to call a C library it's because it's an operating system API or because you want to do things that a VM wouldn't do well anyway e.g. stuff with inline native assembly.
To get back at a higher level - I’m not attacking the JVM - a lot of my career had been using it to much success.
And the large benefits of wasm are still in the making/a bit unclear. In my original post, I question why this runtime is useful at all, as the jvm already does a lot of the same things.
However, GC by default is not in wasm right now, and that enables non-GC languages to be ported over, while it makes no sense to port those languages to the jvm. And a lot of the important stuff is written in those non-GC languages; game engines, gpu compute usage for AI, and others I probably don’t know.
The JVM is old ~ still good/great for backend server side things, but not great for fast startup (50ms is still 10,000’slower than wasmtime’s 5 micro second startup), non-gc stuff, and non-technical, impatient, end user browser stuff.
Hence worth the exploration - and if it means jvm being replaced 10 years later, so be it (maybe there’ll be a Java to wasm port + gc for wasm by then).
You can actually run non-GC languages on the JVM because it does expose a manual memory allocator. That's how the WASM and LLVM support work. In that case the GC gets out of the way (or is used only for Java objects). Of course in that case a lot of the benefits of the JVM aren't there, but if you need to do JIT compilation+manual memory management then it can make sense.
The real question I think is, if it weren't for particular technical choices by the browser people, would anyone care about JIT compiling C? Probably not. We know how to sandbox C/C++/Rust without a JITC, nacl and other initiatives have proved that. Portability, so what - there's really two CPU archs that matter and new ones don't come along very often. Cross compilers work. The GraalVM guys have found a good reason to JITC of C for language interop and interpreter extensions but that's pretty special case.
