[Sandbox] Hyperlight

[squillace]

Application contact emails

[email protected],[email protected],[email protected]

Project Summary

Hyperlight is an open-source Rust library you can use to execute small, embedded functions using hypervisor-based protection for each function call at scale.

Project Description

We built Hyperlight as a library to execute functions as fast as possible backed by real hypervisor-based security. Developers and software architects can use Hyperlight to add serverless customizations to their application that are able to securely run untrusted code. Hyperlight enables these customizations in a wide range of scenarios: for IoT gateway function embedding, usage in industrial automation, high-throughput cloud services, and so on.
Hyperlight is able to create new virtual machines in 1-2 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 virtual machine that provides additional protection in the event of a sandbox escape without the overhead of an entire distribution or boot time.
To give a sense of how fast Hyperlight is, a 1 millisecond cold-start for each VM is fast enough that it becomes practical to spin up VMs as needed in response to events. That also makes it possible to scale to zero, meaning that depending upon your application you might not need to keep any VMs idling just in case any work comes in – or if you do, they can be much, much smaller. That’s not as fast as native functions or sandboxed runtimes. But it is significantly more secure, and about two orders of magnitude faster than traditional VM architectures. Because it does not create VMs with an entire operating system inside, if your function needs that you might still consider a traditional VM with a full distribution.

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/hyperlight-dev/

Project repo URL in scope of application

https://github.com/hyperlight-dev/hypehttps://github.com/hyperlight-dev/hyperlight rlight

Additional repos in scope of the application

No response

Website URL

https://hyperlight.org

Roadmap

https://github.com/hyperlight-dev/hyperlight/projects/

Roadmap context

The issues laying out the formal roadmap are being created at this time. However, here are the objectives we have for Hyperlight over the course of this coming year. Overall, the purpose of Hyperlight is to protect application code from embedded functions at the highest possible creation and invocation speeds relative to the programmatic features required of the embedded functions. Immediate steps include, in order of priority:

1. [WebAssembly components] Ensure efficient and safe usage of WebAssembly components using the wasmtime runtime.
2. [Performance] Ensure that cold-start and running throughput of VMs and functions is outstanding and supports constrained environments.
3. [Security] Obtain an implementation security review.
4. [Security] Full supply chain security automation, including SBOMS and other forms of attestation.
5. [Telemetry and Debugging] Ensure easy OTel export including sampling and enable a debugging experience.
6. [WebAssembly] Add file and networking functionality accessed from the WebAssembly component WASI standard interfaces.
7. [Native Engines] Enable file and networking functionality from native functions.

There are other objectives that are of lower priority but which will happen so long as they do not interfere with the above objectives. Included would be examples like better testing regimes, better samples, and so on.

Contributing Guide

https://github.com/hyperlight-dev/hyperlight/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/hyperlight-dev/hyperlight/blob/dev/CoC.md

Adopters

No response

Contributing or Sponsoring Org

Microsoft Corporation

Maintainers file

https://github.com/hyperlight-dev/hyperlight/blob/dev/MAINTAINERS.md

IP Policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

We see the CNCF as the preeminent cloud-native and community ecosystem foundation. The CNCF provides the framework to create and maintain a healthy ecosystem, enlarge and strengthen the engineering community, and communicate the benefits of the project across the world, both at in-person conferences, local mini-conferences, and in online training. Our perspective is that Hyperlight answers some of the questions that users of Kubernetes and containers have with respect to both fundamental security concerns and its interaction with cold-start speed that extends our abilities for the next ten years of cloud-native. More importantly, we see Hyperlight as one of a series of technology improvements that must be available to the world and not remain part of a controlled, corporate open-source program. The CNCF is uniquely positioned to enable the world to make use of the technology in a public, community controlled way.

Benefit to the Landscape

This adds a hypervisor-based project to the “Container Runtime” category, alongside the optimized but full-distribution hypervisor projects FireCracker and gVisor. FireCracker, for example, is a great project for smaller, optimized but full distribution virtual machines at great speed compared to others. It is documented at 125 milliseconds for a cold start. Like those projects, for example, Hyperlight treats the hypervisor technology as the firmest and most tested of isolation technologies.
Unlike those projects, Hyperlight removes some features taken for granted in order to support cold-start speed. For example, Hyperlight creates micro-vms that do not boot because they do not have an OS; instead, they have only a vCPU and memory isolated from the host application by the virtual machine boundary. They therefore do so much less work that an individual micro-vm can be created “cold” in 1-2 milliseconds, less than 1/100th the cold start of the optimized but traditional hypervisors. In addition, Hyperlight micro-vms are typically extremely small, by default having a 64KB stack size and 128KB default heap size, just enough for a small function. This enables applications of all types to embed customization or pipeline functions in the hot path and offer each function call its own micro-vm, protecting them not only from the host but also from other functions. Finally, this speed gives applications the potential to truly scale isolated functions back to zero – something that can’t be done with traditional VM approaches.

On the other hand, though we believe we can add file and networking support and still keep the cold-start time to well below 1/10th of traditional approaches, Hyperlight functions cannot typically expect to find syscall dependencies, which means that the other Hypervisor-based projects are better choices for xcopying code with OS dependencies as they use full distributions in their virtual machines. Together with those projects, engineers around the world can lean into their chosen technology for their chosen scenario. The CNCF thus hosts the full panoply of choices in “container” runtimes for engineers all over the world.

Cloud Native 'Fit'

Hyperlight is a library that provides an abstraction layer over potentially any hypervisor technology, which gives it the ability to be portable across hypervisors. At the moment, it can be made to run Hyper-V on Windows, Hyper-V for Linux (also called mshv), and on KVM – the engineer does not have to know which one they are using (though they must use the correct release) to build and use a Hyperlight micro-vm guest. It is, as the example just mentioned, able to run on both Windows and Linux, and while Mac support hasn’t been implemented yet there’s no reason it can’t work there.
While Hyperlight does require a created micro-vm guest, that guest can be snapshotted and “immutably” reused in pools, resulting in the same kinds of performance and security gains that containers provide. The resulting operational stance takes advantage of portability, security, the immutability of snapshot-based environment creation to isolate any process both from the host and from other processes at a speed that dramatically increases the execution environments in which it can be used.

Cloud Native 'Integration'

It depends upon some hypervisor technology to execute the guest micro-vm, such as KVM. However, as mentioned, the developer does not have to know which hypervisor it’s using; the abstraction api disconnects the library (and developer) from that knowledge, although runtime behavior will vary slightly depending on what type of hypervisor is being used underneath. (One of the consequences of the Hyperlight project is to find issues with and improve the upstream hypervisor projects as well.) Hyperlight is also a Rust-based project, and leans into the ability of Rust to ensure memory safety.

Cloud Native Overlap

Hyperlight seems to overlap with hypervisor-based projects like FireCracker and gVisor, but the differences are so extreme in terms of speed and functionality of the guest code that there is a clear usage boundary between the projects. For “brownfield” code, for example, which by and large expects to “just run” on one of these projects, users will be thinking about using FireCracker or gVisor, and that should not change. If, however, users have an application into which they want to embed potentially untrusted, user-provided functions to customize the application process in some way, but absolutely require either a) hypervisor-based isolation between host and guest or between guests or b) radically lower resource consumption at speeds that enable dramatically reduced operating costs or c) the ability to work in small memory or reduced execution abilities – Hyperlight is likely a great choice.

Similar projects

While there are many projects in the feature space of extremely fast starts and hypervisor-based isolation (it is always an area of extreme experimentation and research), we do not know of any that attempt to re-use tried and tested hypervisor technology to make it faster in this way.

Landscape

No.

Business Product or Service to Project separation

N/A. This project is consumed by services in Microsoft Azure, but those services consume the project in the same way as they consume Moby or Kubernetes. Our project work is aimed at enabling the best anywhere; Microsoft and others can consume those abilities the same way they consume any other open source project from the CNCF landscape.

Project Domain Technical Review

No we have not. We plan to present it to TAG-Runtime.

CNCF Contacts

Lachie Evenson, Bridget Kromhout

Additional information

No response

[srust]

hi @squillace ! We have a free slot this Thursday November 21st in the TAG-Runtime if you are interested in presenting. We would love to hear more. Please feel free for you or your team to add yourself to the agenda TAG-Runtime Agenda for that time, or for a later meeting date if that works better. Thank you!

[bridgetkromhout]

hi @squillace ! We have a free slot this Thursday November 21st in the TAG-Runtime if you are interested in presenting. We would love to hear more. Please feel free for you or your team to add yourself to the agenda TAG-Runtime Agenda for that time, or for a later meeting date if that works better. Thank you!

Hi, @srust! Ralph is actually taking a much-needed break post-KubeCon, so this Thursday won't work. He will get back to you soon. Thanks!

[squillace]

Hi all, one update. On phone so I'll update the pr later, but the coc link is actually at: https://github.com/hyperlight-dev/hyperlight/blob/main/CODE_OF_CONDUCT.md