Existing WebAssembly runtimes excel at isolating untrusted code within a process, providing a high degree of security/isolation with near-native performance. However, in certain high-security environments, further defence-in-depth layers are required, especially since it is difficult to make in-process sandboxes robust with respect to Spectre attacks, and particularly new Spectre variants. In this talk, I will introduce Hyperlight-Wasm, part of the open source Hyperlight project, which combines lightweight Wasm sandboxing with one of the historically-heaviest sandboxing technologies: hardware virtualisation.

Hyperlight-Wasm uses hardware virtualisation primitives, accesesed via off-the-shelf hypervisors, but eliminates the need for a large guest OS kernel (providing a standard system interface to native guest code) by replacing it with a small Wasm runtime (wasmtime) built into a unikernel. Furthermore, Hyperlight eschews traditional virtual devices like virtual network interfaces, which operate at a low level of abstraction and require duplicated work such as generating IP packets in the guest only to immediately parse them in the host. Hyperlight instead uses a custom paravirtualised function call interface for communication between the virtual machine manager and the virtual machine, enabling the use of application-specific, high-level interfaces between the host and the guest. This approach brings both improved performance and fine-grained access control, similar to that available to any WASI host, to the virtualised environment.

In return for the defence-in-depth assurances of a hardware virtualisation partition, Hyperlight-Wasm has much worse performance than an in-process Wasm runtime. However, it drastically improves the performance of traditional hardware virtualisation solutions while maintaining their familiar security risk profile, allowing it to be deployed in environments which could not support a traditional virtual machine.

Hyperlight-Wasm is also integrated with the WebAssembly Component Model 0.2, allowing the use of a simple programming model which maps naturally to many programming languages for interacting across the hypervisor boundary. As well as the implementation and performance of Hyperlight, I will discuss how both the general programming model of emulating function call semantics for the virtual machine boundary and the specific component model semantics that we are moving towards have informed the design of the entire system.

I will also discuss some of our in-progress work to improve both performance and semantic abstraction in the Component Model and its implementation in Hyperlight, including work to allow the use of zero/single-copy I/O from the host directly into the wasm guest, and supporting the async and stream primitives from the upcoming 0.3 release of the Component Model.

Finally, I will move beyond Hyperlight to summarise several efforts in progress at Microsoft to use WebAssembly in other environments (including its initial home on the Web, local plugin isolation, and extremely resource-constrained runtimes). I will discuss how WebAssembly has enabled isolation in places that it would previously have been difficult, as well as the pain points and issues that we have experienced using WebAssembly.