November 7th, 2024

Hyperlight: Virtual machine-based security for functions at scale

Microsoft has launched Hyperlight, an open-source Rust library that enhances security for executing functions with fast cold start times, suitable for IoT, industrial automation, and cloud services.

Read original articleLink Icon
CuriositySkepticismEnthusiasm
Hyperlight: Virtual machine-based security for functions at scale

Microsoft has introduced Hyperlight, an open-source Rust library designed to enhance security for executing small, embedded functions at scale using hypervisor-based protection. Hyperlight allows each function call to operate within its own virtual machine (VM), achieving cold start times of one to two milliseconds, which is significantly faster than traditional VM architectures. This speed enables developers to scale applications to zero, eliminating the need for idle VMs while maintaining a secure environment for untrusted code execution. Hyperlight is particularly beneficial for scenarios such as Internet of Things (IoT) gateways, industrial automation, and high-throughput cloud services. The project will be submitted to the Cloud Native Computing Foundation (CNCF) as a sandbox project, aiming to leverage community support and best practices. Hyperlight is licensed under the Apache 2.0 license, inviting collaboration from developers and IT professionals to further its development.

- Hyperlight is a Rust library that provides VM-based security for executing functions.

- It achieves cold start times of 1-2 milliseconds, allowing for efficient scaling.

- The project will be submitted to the CNCF for community support and governance.

- Hyperlight is suitable for IoT, industrial automation, and cloud services.

- It is open-source under the Apache 2.0 license, encouraging community collaboration.

AI: What people are saying
The comments on Microsoft's Hyperlight reveal a mix of technical insights and comparisons to existing technologies.
  • Several commenters draw parallels between Hyperlight and other technologies like TinyKVM, unikernels, and Firecracker, discussing their similarities and differences.
  • There is a focus on the performance aspects of Hyperlight, particularly its fast cold start times and execution efficiency.
  • Questions arise regarding the communication between the micro VMs and the host process, as well as the underlying architecture's ability to ensure app isolation.
  • Some commenters express curiosity about the implementation details, such as the use of Rust and potential integrations with existing JavaScript engines.
  • Concerns are raised about the terminology used to describe Hyperlight, suggesting it may not fit neatly into traditional definitions of virtual machines.
Link Icon 12 comments
By @yoshuaw - 5 months
The Azure Upstream team has been working on a really fast hypervisor library written in Rust for the past three years. It does less than you'd conventionally do with hypervisors, but in turn it can start VMs around 2 orders of magnitude faster (around 1-2ms/VM).

I think this is really cool, and the library was just released on GitHub for anyone to try. I’m happy I got to help them write their announcement post — and I figured this might be interesting for folks here!

By @fwsgonzo - 5 months
Looks like my TinyKVM project, except it runs specialized programs instead of regular ELFs? TinyKVM also runs functions, with a fast execution timeout. I proved that without I/O you can essentially run KVM programs with native performance, and sometimes more due to automatic hugepages. I measured LLMs to run at 99.7% native speed using eg. Mistral 7B. For example, the STREAM memory benchmark doesn't use hugepages by default, and so the terminal version runs slower than the TinyKVM version due to hugepage-tables, but of course runs at the same speed once you modify the benchmark to use the same advantage. However, it does require modifying the program.

See: https://ieeexplore.ieee.org/document/10475832

I also implemented VM resets using page-table rewrites and CoW memory sharing, so that no memory is shared across different requests. This can be implemented as tail-latency in a cache.

I ended up adding support for most languages. All the systems languages, Go, v8, LuaJit etc. Go was by far the most annoying to support as it uses signals.

By @generalizations - 5 months
> These micro VMs operate without a kernel or operating system, keeping overhead low. Instead, guests are built specifically for Hyperlight using the Hyperlight Guest library, which provides a controlled set of APIs that facilitate interaction between host and guest

Sounds like this is closer to a chroot/unikernel than a "micro VM" - a slightly more firewalled chroot without most of the os libs, or a unikernel without the kernel. Pretty sure it's not a "virtual machine" though.

Only pointing this out because these sorts of containers/unikernels/vms exist on a spectrum, and each type carries its own strengths and limitations; calling this by the wrong name associates it with the wrong set of tradeoffs.

By @oneplane - 5 months
So in essence, this is somewhere between a unikernel+firecracker combo and a WASM module, but using VT.
By @apitman - 5 months
Don't see any mention of firecracker, which is the first thing I think of in this space. Anyone have a TL;DR comparison?
By @spai2 - 5 months
How does the micro VM's guest API talk to the host process? Does the communication between the two have to go through the hypervisor?
By @spankalee - 5 months
They mention that most guests are expected to run code in a VM/interpreter... I wonder if they have a build of V8 or JSC for their environment?
By @u8080 - 5 months
So in general this is kludge to implement app isolation via "VM", because existing CPU architectures suck at isolating code?
By @sim7c00 - 5 months
i wondered how it worked in rust but the guest entrypoint>init>main is wrapped in unsafeblock as is a lot of other low level operations it does. interesting stuff
By @broknbottle - 5 months
Cool to see them using just
By @7e - 5 months
Use CHERI for this?