I'm a little fuzzy on the multitenant security promise of WebAssembly. I haven't dug deeply into it. It seems though that it can be asymptotically as secure as the host system wrapper you build around it: that is, the bugs won't be in the WebAssembly but in the bridge between WebAssembly and the host OS. This is approximately the same situation as with v8 isolates, except that we have reasons to believe that WASM has a more trustworthy and coherent design than v8 isolates, so we're not worried about things like memory corruption breaking boundaries between cotenant WASM programs running in the same process.<p>At the end of the day, if your runtime relies on a whole shared OS kernel, you have to be concerned about the bugs <i>in the kernel</i>. That's true of VMs as well, but to a much more limited extent: KVM is (by definition) much smaller than the whole kernel, and KVM bugs are rare.<p>I'm writing this mostly as a provocation; I don't have a clear enough understanding of backend WASM multitenant security to have strongly-held opinions about it.
So far in my experience WebAssembly has been great for when I want to import a *little* bit of native code into my browser. I've yet to see it work well as a full on container based solution. I could certainly see a future where that is true, but it'd need the following:<p>- A way way better tooling story. Emscripten is an incredibly fiddly tool that requires a lot of flags and config. wasm-pack is decent for Rust but seems to be focused on the browser.<p>- Better interoperability. WASM works great if you write everything in Rust, or everything in C or everything in Zig. Not so much with multiple languages.<p>- Memory64 and WASI need to land. We need more than 4 gigs and we need proper syscalls.<p>- Near native needs to be, well, near native. I find it weird that people keep on saying WebAssembly is fast while in the same text decrying "a low-double-digits percentage hit" in performance. I'm fairly certain WebAssembly's "near native" is using near to mean "same order of magnitude", not "within 10%".<p>I'm also just confused as to what WebAssembly will look like for something that's more than a lambda conceptually. Like if we're running a classic back-end server with a database, are we going to run the database in wasm? Are we running it in a different wasm process? How do you share memory? Is wasm going to reinvent the operating system?<p>I like WebAssembly as an idea but I'm very unclear on how it'll get to the "replace Docker" level.
The article says whether a language runtime like v8 is a stronger security boundary than a hypervisor is a matter of debate, however v8 has boatloads of CVEs and the further isolation of browser sandboxes has been a driving factor in OS development for nearly two decades. Meanwhile, multiple Fortune 500 companies bet their multi-billion dollar cloud businesses on the security of their hypervisors.<p>So when the author links to a confused HN thread about whether the v8 runtime is a security boundary and says "looks like there's debate", it makes the article look like a joke.
It is so tragically funny whatching everyone re-inventing mainframe language environments, JVM application servers and the CLR.<p>> > One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language.<p>-- February 2002 issue of MSDN Magazine<p><a href="https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/february/editor-s-note-welcome-visual-studio-net" rel="nofollow">https://learn.microsoft.com/en-us/archive/msdn-magazine/2002...</a><p>It is as if a newer generation never bothered to learn about what came before.
This article says of Fly: "but they don’t scale down to zero".<p>This isn't entirely true. A little known aspect of Fly Machines is that you can stop them and they will be automatically restarted by the Fly router (with a very short cold-start pause) when the next request arrives. So you can scale them to zero if you do a bit of extra work.<p><a href="https://fly.io/docs/reference/machines/" rel="nofollow">https://fly.io/docs/reference/machines/</a> hints at this:<p>> Machines are also the spawning ground for new platform features like wake-on-request (also known as scale-to-zero). You can stop a running machine to save on compute costs. It then may be started automatically when a request arrives at the Fly proxy.
I suspect that WebAssembly is actually the wrong abstraction here, and you might want something a little closer to BPF for non-process-isolated serverless compute, but also not BPF because BPF can do arbitrary memory reads. WebAssembly appears to be too permissive for this case, and BPF too restrictive to be useful.<p>Ideally, if you could have a language-level VM that guarantees that you only ever read or write data inside memory allocated to you and calls a limited set of syscalls (which you intercept/rewrite at compile time), you probably don't need any other protection.
On Micro-VM's specifically, shout out to Wyrcan[1], which is open source software similar-ish to Fly.io in taking a container image & booting into it. There's no platform here, but it's an advanced & secure bootloader for a container images that looks like the core critical capability furthest under the hood.<p>Back to isolates, I'd really love to see v8 isolates gain some more whatever it takes for people to be less critical about it's multitenancy. I havent really understood what the criticism is but it's fairly active. Since the process has to do it's owm scheduling of work, just having something like cgroups & resource priority seems like a fairly obvious absense: make sure everyone gets a turn. This scheduling seems semi obvious. But I think the security-minded folk are paniced over a lot more, and likely with legitacy, but the name isolates is afaik somewhat reasonably truthful, that data is fairly secure across isolates in the same process.<p>Throwing in a bonus ask, it'd be sweet if isolates could migrated. Perhaps snapshotting can already maybe do this? Being able to load manage is important! Even if v8 doesnt want to have vast multi-tenant scheduling capabilities my trivial dumb feel is that just moving aggro processes elsewhere would be a great start to handle aggressive tenant sub-proceeses.<p>I wish I had links on hand, but one of the things that most opened my horizons on wasm & it's role was considerations that browsers should be able to have multiple instances of a module. Like, if someone depends on a module, does everyone always get the one singleton instance? Can the browser start creating multiple instances if there's a lot of consumers? Very clear browserside question that really opened the floodgates that, oh, there's a lot of ways we could go forward with this!<p>[1] <a href="https://gitlab.com/wyrcan/wyrcan" rel="nofollow">https://gitlab.com/wyrcan/wyrcan</a>
What is it with these companies who have untold resources, and scores of the smartest engineers, yet what they do is repurpose some existing tech that kinda works instead of building stuff properly?
Like selling:<p>- The browser scripting engine as a PaaS engine<p>- The VM language/runtime meant for running binaries in the browser as a PaaS engine<p>- The tooling meant to isolate Linux processes as a VM platform<p>Can't they build tech properly, for their own purposes?<p>Not to mention, the whole exercise seems like monkey-patching over the failures of modern OS design. A proper operating system should be able to run <i>processes</i> with zero trust and resource sandboxing.
Towards the end of the article it sounds like the author was looking for this:
<a href="https://github.com/deislabs/wagi" rel="nofollow">https://github.com/deislabs/wagi</a>
The JS / wasm ecosystem is slowly becoming Java / JVM. Wasm has a virtual machine that can run wasm code, which different languages can target with a specialised compiler. It also abstracts away things like memory, storage and networking, just like EJB did.