I am more convinced by the day that the Nova Microhypervisor approach is correct.
Do virtualization with a tiny formally verified microkernel and have complex kernels like Linux run underneath instead of having a huge, complex, and brittle linux kernel and vm ecosysem control the hypervisor layer.
How is this different from Xen? It's the same approach as Xen or Hyper-V where the hypervisor is its own component, then you boot into a virtualized Dom0 or Root Partition (in Xen and Hyper-V terminology respectively) that can manage the hypervisor underneath it.
This is different from KVM where your hypervisor runs in your Dom0/Root Partition.
This is a much lighter weight (~100k) alternative to Xen focused on baremetal TPM anchored remote attestation, formal verification, and trusted computing applications.
Anyone considering Xen should probably also consider Nova depending on requirements.
This is not a new vulnerability, it's just a description of how to exploit the PwnEscape vulnerability (already discussed at length on HN) in practice on firecracker VMs
I am more convinced by the day that the Nova Microhypervisor approach is correct.
Do virtualization with a tiny formally verified microkernel and have complex kernels like Linux run underneath instead of having a huge, complex, and brittle linux kernel and vm ecosysem control the hypervisor layer.
https://hypervisor.org/
I don't know much of anything about Nova but since the late 1990s this has also been the pitch for L4; there are several mature L4's.
Nova is L4 inspired, and interchangable with L4 kernels in Genode.
How is this different from Xen? It's the same approach as Xen or Hyper-V where the hypervisor is its own component, then you boot into a virtualized Dom0 or Root Partition (in Xen and Hyper-V terminology respectively) that can manage the hypervisor underneath it.
This is different from KVM where your hypervisor runs in your Dom0/Root Partition.
Xen had a generic guest to host vulnerability disclosed in the last few days: https://codeant.ai/security-research/xenbleed-a-grant-copy-c...
This is a much lighter weight (~100k) alternative to Xen focused on baremetal TPM anchored remote attestation, formal verification, and trusted computing applications.
Anyone considering Xen should probably also consider Nova depending on requirements.
> the Nova Microhypevisor approach is correct
To save people the time:
"This code is experimental and not feature complete. If it breaks, you get to keep both pieces."
The actual main open source repo is, yes, but commercial forks are deployed in production government and high risk use cases.
See his latest talk which represents a lot of impressive recent work: https://cfp.3mdeb.com/media/bsmconf/submissions/KW3SYT/resou...
I am working on a production OS using it as a foundation.
I have a demo service that entirely relies on Firecracker VMs: ClickBench playground, https://benchmark.clickhouse.com/playground/
It hosts hundreds of database engines - many of them have vulnerabilities, and some of them, like Pandas, are basically open RCEs regardless.
We can PoC the Firecracker VM Escape on that service.
This is not a new vulnerability, it's just a description of how to exploit the PwnEscape vulnerability (already discussed at length on HN) in practice on firecracker VMs
Firecracker VMs run on AWS. Odd that the article doesn't mention that.
Firecracker is open source and possibly others use it, AWS sells services with it though.
(A more complete way to say this is that Firecracker is the engine built to run AWS Lambda and AWS Fargate).
It has notable adoption in the agent sandbox space where this type of vulnerability is especially volatile.
> The target was Firecracker v1.16.1 on x86-64, with host kernel 7.0.0-1011-aws.
it's really informative. At least someone are break it.
This is pure LLM slop.