Our great sponsors
-
-
cloud-hypervisor
A Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
crosvm
The Chrome OS Virtual Machine Monitor - Mirror of https://chromium.googlesource.com/crosvm/crosvm/
It's a niche use-case, but one of the things I've been curious about is nested virtualization using Firecracker as the outside VMM and KVM as the inner VMM (and the sole userspace process running in the Firecracker VM). This would make it possible to use Firecracker for whole-system virtualization, and emulate Windows.
This is apparently technically possible and just works thanks to Linux' support of nested virtualization, but celebratory noises to that effect elicited a slightly freaked out response: https://github.com/firecracker-microvm/firecracker/issues/17...
That issue only really covered the security impliciations of multiple KVM (QEMU) instances inside a given Firecracker instance, which I can totally see as (strictly, pedantically) problematic. But if QEMU is literally the only thing running (besides an only-what's-necessary /init) in a given Firecracker instance, that sounds to me like I'd have the best of all the worlds (Firecracker's awesome security and hardware emulation).
The only ramifications I can see are if the hardware acceleration involved in nested virtualization might represent a security vulnerability. Theoretically such a vulnerability would equivalently impact Firecracker-inside-Firecracker use cases, assuming that a theoretical attack would need to break out of QEMU and then Firecracker, as opposed to *waves hands* doing something that punches all the way from the twice-VMM'd guest all the way out to the host.
I'm not sure, but maybe because it started as a fork of crosvm[0]?
[0]: https://github.com/google/crosvm