Hyperlight WASM: Fast, secure, and OS-free

I agree that some things are essential, and there's value in specifications. The question is how likely is the current tragectory to follow what happened with browsers? The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it?

Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? Because that's how you end up in the situation where the "user agent" with majority market share starts gutting ad blockers.

I'm not saying I'm predicating this will happen with WASM or even think it's very likely. I don't know enough to have a real opinion on that. I'm just saying I really really don't want it to happen.

> A standard instruction set, standard calling convention, and standard syscalls.

This sounds like an OS like user space to run atop WASM similar to POSIX.

Standards are good but my hope is the design is well thought out.

Thank you for Exstism. My main request is that you keep the core interface as simple and forkable as is feasible. You're certainly incentivized to make it as complicated as possible so only your team can maintain it, but I hope you're able to find a sustainable business model that doesn't go down that path.

Roughly the same reason as every time someone asks the same question in any post that mentions WASM: Java is a particular model with a particular view of the world, tied to a GC and a particular standard library and various hard limitations such as no user-defined value types that make it impossible to compile C code to properly and run it with reasonably C-like speed. Just because Java has incorporated dozens of 'advances' doesn't mean any of them address its longstanding problems, and you're mixing implementation tech with spec design in your reasoning. You, in your daily life, likely use zero software incorporating Java and multiple pieces of software incorporating WASM. You cannot imagine using Java for shaping functions embedded in font files, or sandboxed 'native' modules in a JS-based text editor, or blockchain smart contracts. In fact Java basically cannot be reliably sandboxed at all.

Because WASM is currently solving a real problem for me that Java can't solve, ie easily embedding code I wrote in one language into many other languages. You can do something similar with shared libraries, but you have to compile them for every architecture and OS and solve the associated distribution problems. Ask Python and JS how that works out in practice. A WASM artifact runs everywhere, and has addition security benefits.

Seems to have a lot more momentum though? I can run Haskell on WASM, and all the backends for JVM and CLR are long dead. More to the point, I can target the browser without plugins, lock-in, or security problems.

When you jump into every WASM thread with this take, what are you trying to accomplish?

Though both share the ability so securely execute multi-tenant workloads, but they make very different tradeoffs when it comes to compatibility vs performance. To compare:

Firecracker is great if you want to securely execute an OS image. It has the benefit of compatibility with many existing programs, but that comes at the cost of some overhead.

Hyperlight is great if you want to securely execute program runtimes. This requires bespoke guest bindings, but it has the benefit of having less overhead.

There’s a place for both approaches, and I see both happily co-exist.

From what I understand Hyperlight's boot process is more similar to a microcontroller than a PC (although it use your CPU architecture) - the VM directly boot into your code. Unlike Firecracker, Hyperlight VM doesn't have any hardware while Firecracker do have VirtIO devices, serial console and keyboard so that traditional operating systems can be adapted to Firecracker. Host-Guest communication is done with shared memory.

It depends on how which performance metrics you're interested in, where you draw the boundaries for individual workloads, and how you then schedule those workloads. Hyperlight can start new Wasm workloads so quickly that you might not need to keep any idling instances around ("scale to zero"). That's new, and it makes comparisons a little more complicated. For example:

- If we take VMs as our boundary and compare cold start times, Hyperlight confidently comes out on top. That's 1-2ms vs 125ms+.

- If we take warm instances and measure network latency for requests, Hyperlight will come out on top if deployed to a CDN node (physics!). But if both workloads run in the same data center performance will be a lot closer.

- Say we have a workload where we need to transmux a terabyte of video, and we care about doing that as quickly as possible. A native binary has access to native instructions that will almost certainly outperform pure-Wasm workloads.

I think about Hyperlight Wasm is as yet another tool in the toolbox. There are some things it's great at (cold-starts, portability, security) and some other things it isn't. At least, not yet. Whether it's a good fit for what you're doing will depend on what you're doing.

You are spot on. I was loose with my terms. I was thinking safe in the concept of sandboxing the host, but you are spot on, it isn't memory safe.

Why is 'more memory safe than just having the application running in a separate process' the benchmark? Literally nothing can clear that bar. It is more memory safe than most existing VM languages, which is all anyone actually cares about.

WASM Components are supposed to be memory safe, even in-process. Besides, you can compile from a memory-safe source language to WASM.

[flagged]

That reminds me of the time when Java applets had their high time.

I think that WASM in the browser will either largely replace JavaScript or will wither away like Java applets did. I fear there is no in-between and if it is only because no one will support two languages and ecosystems in parallel and in the long run. Not the big companies and certainly not the small ones.

That is not the world I see. Where is WASM in the browser really used apart from crypto miners?

The world I see is one where WASM is a permanent second class citizen and probably already has reached its peak adoption.

Not that I hope for it, quite the contrary, but that is what it looks to me.

EDIT: crypto miners and fancy tech demos I should say

Thank you for the illuminating references! So this sockets example is a host that runs on a raw vm (x86_64-unknown-none target) and spawns sandboxes. To get at my original idea, I could imagine a sandbox with special functions imported from the host that can spawn new sandboxes. This could be complicated by the fact that spawning these sandboxes and hooking up inputs/outputs seems to be statically compiled...

I wondered how components were supposed to be used. So wac takes a group of wasm components and merges them into a new .wasm file with inputs/outputs mapped according to a defined .wac file. Then you can just run the new .wasm file. Does this not obviate the isolation benefits of having separate wasm modules? Is there a path to running a tree of components directly while maintaining the sandbox between them?

The reason processes aren't enough for isolation is primarily because of the large (and growing) number of syscalls, especially for complicated, bleeding-edge subsystems, exposing significant kernel surface area that's susceptible to exploits when kernel bugs are discovered.

The WASM ecosystem is recapitulating this stage of affairs by increasing the surface area with external systems in the same fashion.

Unix processes combined with seccomp (or pledge) to reduce exposed kernel surface and landlock (or unveil) to limit filesystem access puts you back at square one. Processes running WASM interpreters should be leveraging those interfaces, anyhow. What really differentiates WASM is the "compile once, run anywhere" portability allure.

But we live in an age of open source (in the literal sense). Ecosystems like Go and Rust assume source code availability; binary blobs are the exception. There's not much of a difference between C, Go, or Rust textual source code on the one hand and a WASM binary on the other; both are going to be compiled to native code by the downstream user. When you have the source code available to compile, then standards like POSIX should suffice. But they don't (at least not completely), because people are always chasing newer features that various environments invent to differentiate themselves. I don't see how WASM resolves that fundamental dynamic. Though I don't deny there are marginal benefits, just like there were with the JVM, which in many niches effectively resolved the Unix/Windows portability issue, allowing people to migrate platforms easier as preferences and requirements change.

Right but the course of action should be to add on to them, not invent entirely new stacks.