Hyperlight WASM: Fast, secure, and OS-free(opensource.microsoft.com) |
Hyperlight WASM: Fast, secure, and OS-free(opensource.microsoft.com) |
WASM is in an interesting place. The value has clearly been proved with a pretty minimal core spec. Now there's a big push to implement a much larger API surface for WASI and the Component Model. A lot of people in the community are concerned about this direction, or at least the way it's happening[2].
For my part, I hope WASM doesn't go the way of the rest of web browsers where it gets so complicated that only big tech is capable of making implementations and experimenting.
[0]: https://github.com/lastlogin-net/decent-auth
[1]: https://extism.org/
[2]: https://www.assemblyscript.org/standards-objections.html
- Wasm is a (virtual) instruction format for programs to be compiled into (think: x86).
- Wasm Components are a container format and type system that wrap Core Wasm instructions into typed, hermetic binaries and libraries (think: ELF).
- WASI is a reserved namespace for a collection of standardized Wasm component interfaces (think: POSIX header files).
To reach our goal of having shared, portable binaries that aren't locked into any one vendor we need all three. A standard instruction set, standard calling convention, and standard syscalls. Wasm Components and WASI might not be necessarily be perfect, but at a minimum they're targeting the right scope. And that carries essential complexity.
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.
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.
As you know, we're all about delivering value with the actual standards today. This means using truly portable, w3c Wasm core modules. Not some "maybe in the future" standard a la Components.
If you realistically want to use Wasm everywhere, in practically every language, Extism is the way to go and we're in it for the long haul.
For those who appreciate the WIT IDL being worked on (now for way too long), we support a far simpler, more familiar OpenAPI based version to eliminate the boilerplate of type conversion & serialization across the guest-host boundary, worth checking out: https://github.com/dylibso/xtp-bindgen
Java's subsequent development was driven by enterprise/containers (mainly Oracle), and the VM has stayed relevant for 30 years by incorporating dozens of advances in machine and programming models. Both successful and lamentable.
If WASM (i.e., the loose collection of organizations driving it) could do it better than Java, wouldn't Java (with all its resources and organization) have already done it?
The answer has to lie in unsustainable or limiting technical decisions. What exactly are the design decisions WASM made to make it seem like it would escape becoming Java-like?
Today we’re happy to announce the Hyperlight Wasm guest based on the Wasmtime runtime. This makes it possible to run Wasm Component binaries on top of WASI interfaces without the need for a guest OS in the VM. In this post we explain how this works and walk through an example.
> Hyperlight is able to create new VMs in one to two milliseconds. While this is still slower than using sandboxed runtimes like V8 or Wasmtime directly, with Hyperlight we can take those same runtimes and place them inside of a VM that provides additional protection in the event of a sandbox escape.
[1]: https://opensource.microsoft.com/blog/2024/11/07/introducing...
Maybe we should drop the Web from Web Assembly and call it something else?
[1]: https://dropbox.tech/tech/2018/06/building-better-compressio...
[2]: https://thenewstack.io/adobe-developers-use-webassembly-to-i...
[3]: https://www.figma.com/blog/webassembly-cut-figmas-load-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.
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
As I understand it this is designed to sit on bare metal and this is all a bit hamfisted but I don’t have a spare bare metal x86 around.
Guessing just throw this into a vm and accept that it’s nested virt?
Can you give a Wasm Component binary the capability to execute a tree of connected Wasm Components, delegate capabilities, and manage their life cycle?
As for executing a tree of connected components, in the current state of Hyperlight-Wasm you'd probably want to take a collection of components and compose them together using something like https://github.com/bytecodealliance/wac to create a final component composed together from multiple components.
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?
Have we ever thought of .... Using Unix processes for what they were meant to do, which is .. isolate programs?
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.
Instead of WebSphere, WebLogic, IIS et al, you get Hyperlight WASM, with WASI components (aka CORBA/DCOM).
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.
- 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.
For example, https://mcp.run is one such business we are very excited about — and it is Extism at the core. No modifications to the runtime, just the same Extism we all know and love.
And we want way more than our own team to help maintain the open source project, no doubt about that! So simplicity and transparency are the name of the game.
The big change going from WASI 0.1 to WASI 0.2 is that we decoupled the calling convention (Wasm Components) from the actual syscall APIs (WASI). That enabled us to make the various syscall APIs modular and composable.
Because CDN functions probably shouldn't know about TCP; and CLI applications probably don't care about blob storage. And now they don't need to. Take a look at the WASI Proposals page [1] for an overview of all WASI APIs.
[1]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md
Thanks for the link. I was trying to find a single page with everything listed.
What happened to browsers? Few vendors implementing them? There are still 3 major vendors supporting an open source runtime or two (Google and MS on Blink), and a good open implementation (Mozilla). Better than 20 competing engines, does anybody miss IE's own engine?
And with WASM it's way easier for multiple implementations to be written, if need be, as it's a language runtime. These have 1/100th the scope of a browser (which is 99 other very hard to implement things PLUS a WASM runtime).
>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?
Because "let third parties define and write basic libraries" (and sockets and http are very basic) has been a disaster every time. You get a fragmented ecosystem, several popular libs fighting it out, and users either stay away or suffer the consequences.
At least with an official spec implementations will be compatible, and we'll get some reference one.
You can also have a standard web assembly component that simply implements wasi-http on top of wasi-sockets.
That's just not true. Every language that doesn't allow casting pointers to integers (that is, JVM, Javascript, Python and literally everything but C/C++) is more memory-safe that WASM. Yes, performance on these more or less sucks. But what I'm trying to tell, the only advantage WASM has over native code is portability, it's no more safe than native code, most interpreted languages (where "interpreted" includes bytecode and JIT) are safer.
> fully sandboxed embedded system, of which Java is not
How so? Nothing stops JVM from sandboxing within the same address space. Then the java API breaks sandboxing in many intended and unintended ways, but the advantage of WASM here is that it doesn't provide a standard API at all - every attempt to provide same functionality will run into similar issues.
JavaScript and TypeScript are great languages with excellent Web integration, whereas wasm is focused on pure computation (forcing it to bundle its standard library, for example). But wasm has predictable performance that is close to native builds, and sometimes you need that.
Very few web pages use only wasm. Most uses of wasm on the wasm are as part of a JavaScript site, for the parts where wasm makes sense.
The danger for WASM is that JavaScript doesn't stand still either and we might as well see improvements that make the gap to WASM's selling points smaller.
Rather, what we're likely to see is work which makes integration between wasm and JS easier - see, for example, the wasm string builtins proposal [1], the proposal for native support for importing wasm from JS [2], or the proposal for fixed-layout JS objects which would allow directly reflecting wasm-GC objects in JS [3].
[1] https://github.com/WebAssembly/js-string-builtins/blob/main/...
[2] https://github.com/WebAssembly/esm-integration/tree/main/pro...
[3] https://github.com/tc39/proposal-structs?tab=readme-ov-file#...
You are free to ignore my comments.
But in the WASM case, to what end? There's a cost to your comments. I'm sharing an example of how WASM has helped me solve a real problem, and might solve real problems for other people. Your comments create noise to these types of discussions.
Maybe it's worth the tradeoff in your mind, but I'm curious what your end goal is?
Making the same comment on every single Webassembly thread for the last couple years as if the everybody working on WebAssembly or WASI is some bro-programer born in 2008 is just disrespectful to the engineers working on these projects.
Sorry that we are not all as cool as you and use UNCOL everyday. I mean who would want to use a technical idea that isn't first of its kind.
That was already possible with Haskell to JavaScript.
Java not only is pretty much alive on the server, so is .NET, Erlang, and plenty of compiled languages that have always been a better alternative to JavaScript.
Art and design: Photoshop, Figma
Games: Unity, many other engines or components inside engines (e.g. Bullet)
Videoconferencing: Zoom, Google Meet, etc.
Productivity: Google Sheets
Other: Google Maps and many, many more. For example, here is a talk about how Google uses wasm in a large range of its products: https://www.youtube.com/watch?v=2En8cj6xlv4
Look, wasm is a supplementary technology, used where JavaScript isn't good enough, like all the examples I just gave. Those use cases work extremely well right now, and most users on the web benefit from wasm, even if they are unaware wasm is running on the page - which is how it should be.
That is exactly the success that wasm aimed for from the start.
I see your point and I see and love the advantages of WASM but I doubt they will be enough to outweigh the burden to support two ecosystems in the long run. Support in the browser, as well as on the development side.
"That is exactly the success that wasm aimed for from the start."
If this is true WASM has been doomed from the start. If WASM doesn't set out to eat JavaScript's cake it will be left with the crumbs and slowly but surely starve to death.
Java applets were plugins, which led to security issues, and worse, security issues not under the control of the browser. Wasm is a proper part of the browser.
Java applets had limited interop with JavaScript and HTML. Wasm is also somewhat limited there, but it was designed to at least have fast calls to JavaScript itself.
Java also has language-specific issues. Most native code that people want to run on the web is not written in Java or another JVM language. Wasm was designed to support compilation from C++, Rust, etc. (and it has recently added Java support too).
E.x. the Cobalt video downloader has an experimental on-device video remuxing feature that uses FFmpeg (libav) compiled to WASM. It's a win-win for both the provider (who saves on hosting and bandwidth fees) and the user (who enjoys snappier functionality and enhanced privacy guarantees.)
Amazon's Twitch service (and by extension also AWS's Interactive Video Service product that uses all the same backend stuff). Their video player is either fully a WASM thing or has some WASM components, I'm not completely sure which.
See, that's the problem. As long as WASM is not able to pull its own weight and needs JavaScript to provide the spine it will languish in a niche or two. Ultimately someone will decide that supporting two different languages and ecosystems is too expensive and not worth the marginal advantage and it will go back to JavaScript only.
We've been there and we have done that with Java applets.
Those libraries are not something will be able to be JS only anytime soon, and no, Java applets has never allowed us to use C/C++ libraries on the web before.
I though you meant it isn't used by web developers, which it very much is.