I really wish they would have expanded on this paragraph in their article further:
> The configuration used here had no jailer. Firecracker's production containment includes dropping privileges and restricting the process through namespaces and seccomp. A deployment using those controls requires a separate assessment of the privileges and resources available after compromising its VMM.
If I'm understanding all of this correctly, a properly jailed and configured firecracker instance would greatly reduce the blast radius of this escape, and I feel as though it would have been good for them to explain what jailing and dropping privileges would do to help. I'd hope most production firecracker deployments would be doing this already.
Not saying that this is any less severe and the root issue is not specific to Firecracker, but to a flaw in the kernel's network code -- they just used an insecure firecracker configuration to demonstrate it. However, I feel like some are taking this as a flaw with firecracker when its not. This is an issue in the kernel networking stack.
That's a good catch. Yes, since they've only proven this up to the jailer boundary, you'd need a second and relatively powerful LPE vulnerability to get real host control out of this.
Thanks to frontier reasoning agents, Linux is completely riddled in ways you can discover 900+ LPE vulnerabilities. [0]
Another wave of vulnerabilities like this are yet to be discovered in Linux. We are just seeing how weak C and C++ based OSes and kernels are when put under hundreds of AI agents.
you sure the people who caused this (speeding up Linux to mainly serve ads instead of hardening it?) aren't the exact same people now pushing the antidote?
And how many of these vulns are in code for legacy hardware or filesystem support that in no way reflects threats against modern Linux installs? I wager the overwhelming majority of them.
We always knew this, it has been understood since nearly the dawn of the monokernel OS that there is always a route to privilege escalation somewhere. This is why even for web applications that would be better served by a shell, people choose CGI-style interfaces instead.
The only reason it wasn't seen as a problem was due to the effort and time it took to find and exploit them.
Nope. The exploit compromises the host kernel. The researchers built an unconventional exploit chain in which they used the host kernel compromise to compromise the host firecracker userspace code, but I see no fundamental reason they couldn't have compromised something else in the host kernel.
Wait, this is also presumably true, come to think of it. I'm a little fuzzy because they document the memory disclosure primitive carefully but not the memory writes they also got from it --- but whatever those are, they're hitting kernel memory? But the exploit they're describing here gets code execution out of Firecracker itself, not the kernel.
AIUI they’ve chosen as their target the host userspace pt_regs, i.e. the kernel structure that stores Firecracker’s register state. If they can find it and write to it, they can control the complete register state of Firecracker.
I assume they chose it as their target because Firecracker, like most Linux KVM userspace [0], maps guest memory into its own address space, giving an easy place to write gadgets.
My personal favorite thing to poke into pt_regs is an actual privileged (CPL0) context. [1] Returning from the kernel right back to a controlled kernel context is allowed by the CPU :)
[0] Until fairly recently this was mandatory. These days it’s possible to ask KVM to map something into the guest without having it in host userspace memory.
[1] Corrupt pt_regs so it executes user memory in kernel mode:
I think this may be my favorite of all exploits I’ve ever written. In fact, I often made a point of not writing interesting exploits for corruption bugs I found, but this one was too much fun to pass up.
Yeah, they're not saying a lot there. And then the proof of concept code is just being passed the physical addresses of the pages they talk about as command line args, and is just opening /dev/mem to do brain surgery on them.
Which like, isn't really a proof of concept of anything being described.
It's a super good bug! I just don't follow the exploitation details all the way. I know more than one cloud provider panic-bounced their fleet in response to it, and I think that was the right call.
It just bothers me that the proof of concept starts with the assumption that host physical memory is mapped into guest physical memory at 2^39. If you can't talk about the actual exploit yet, I get it , but don't write a blog post with something like that called a "proof of concept" when the code shows no exploit, and you're obviously dancing around the actual novel exploit here in the chain. Just keep it in your pants until the disclosure window.
I was reading through and thought "surely I missed a step here" in more than one place.
They mention in part 1 having a write primitive that can hit a 64 byte region, but never really explained how that worked. I'm guessing this was them being able to have checksum offload write TCP/UDP checksum values into the overhang region past the valid data. Maybe the memory map was set up that way, but obviously relies on getting really lucky with getting their page table in the next page after their packet.
Also it was never called out, but as far as I can tell their exploit should only be able to target the beginning of pages for reading/writing. In order to rug-pull the socket logic that reads the IP IHL field, the IP header content needs to be in a page mapped to the guest. The only useful way to use this attack is to have the region spill out of the guest page into whatever page comes next in the kernel's memory map. (Which also makes the mentioning of the skb linear header kind of confusing, since that would be in a completely unrelated kernel memory region, and just have the data pointers pointing into their data, which is what happens for zero-copy network drivers, which presumably was set up for the kvm network for them to retain guest control over the packet.)
The malware infection has been identified as Clang, part of the LLVM threat actor. To clear this infection unlink the directories named /dev and /proc on Ubuntu.
yup, the other firecracker escape recently (https://www.coinspect.com/blog/firecracker-escape/) popped the jailer via io_uring (tl;dr firecracker was filtering syscalls appropriately with seccomp, and was filtering the uring _they_ initiated, so attacker just got them to pop a new unfiltered uring, which is rather nice).
Just for what it's worth, that escape is much more situational than PwnEscape (there have been other escapes that depended on nested KVM, as well). Pretty much everyone seems to have been exposed with PwnEscape, because everyone using Firecracker is also using virtio-net.
They ran it without a jailer, and exploited a bug in the linux socket code. Firecracker was just how they invoked/worked with /dev/kvm. It is not a firecracker bug. Its sensationalist nonsense.
It's very much a Firecracker thing. KVM is part of the Firecracker stack, and getting code execution behind the jailer is still effectively game-over; it's just a somewhat higher degree-of-difficulty game-over. It's a drastically worse place than you would have been last year, when there wasn't a known plausible way to get even that far.
This is a really good bug and nobody should downplay it.
Both, maybe? I mean: whether or not they broke the jailer, we know the jailer is breakable; it wouldn't really even be newsworthy to have an LPE that breaks the Firecracker jailer.
I deeply love my idiot comment about not using password for your password generated useful stuff. Kudos to everyone here who rescued my idiocy. Now to change my luggage combination.
Could you please stop posting unsubstantive comments, flamebait, and personal attacks? You've unfortunately been doing these repeatedly, and we ban such accounts.
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 letting a huge, complex, and brittle linux kernel and vm ecosystem 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.
Yeah, all security design guarantees are as good as the implementation at the end of the day. All the fancy hashing and encryption math in the world isn't gonna save you from an erroneous `"" == ""` check or an invalid reference check.
I was replying to OP saying it's the same "approach" as Xen, if your preference is "approach" based. It's fair though to point to Nova's smaller code base. It's becoming an important metric for me in general (how big is the code base). It's not a bullet proof thing, but having a smaller code base is a positive sign in 2026 for me.
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.
Is there a well tested L4 hypervisor solution with hardware accelerated virtualization and raw TPM support formally verified to a similar or greater level than Nova with similar remote attestation and security features?
Most of the L4s have hypervisor situations. I don't know about TPM support. Generally the vibe I get from systems security people is a bit of eye-rolling about the formal verification of things like L4; the real win is just drastic attack surface reduction.
And then, of course, L4s live in millions and millions of shipped products, which is a reason to consider L4 instead of something novel, but I'm not saying you should or shouldn't.
I for one do not want any code in the TCB that is not formally verified, tiny, and easy to audit with every line of code justified.
SeL4 is the only open, mature, and formally verified L4 solution I am aware of that can run on modern servers, but IIRC given vCPUs are not first class objects and any low level CPU virtualization features are handled in user space, it comes at a real performance cost making it only suitable for single-core or non-performance-critical applications.
Nova by contrast was built to handle the expensive and trust critical TPM and vCPU handling directly for high performance remotely attestable multi-core applications without having to reach for something as heavy as Xen, though formal verification is admittedly not as complete as SeL4 yet AFAICT, though lots of recent progress here.
Those are pretty big tradeoffs, but if you or anyone else knows other viable xen alternatives this general shape with a tiny easily-auditable footprint, please chime in!
Like some of what I'm saying is just that if you tell a systems security person "we're using seL4 because of its formal verification", you're going to get eye rolls. Whatever else you want to say about it, the formally-verified configuration of seL4 doesn't actually do much, meaning whatever system you're building on top of it is going to be where all the security drama is anyways.
I'm certainly not telling you to use Xen. I wouldn't use Xen for anything untrusted.
> the formally-verified configuration of seL4 doesn't actually do much
As a systems security engineer myself I would disagree and know several others that would as well. All depends on your circles, applications, and threat model I suppose.
Xen, Hyper-V, and KVM have all had major security flaws in the form of logic violations, spacial memory corruptions, use-after-free, and pointer corruptions that allowed hypervisor trust boundary violations. I expect most if not all of those classes of bugs could have been prevented by formal verification.
Xen likely has a bad reputation with both of us because of a history of preventable flaws like these.
In my applications every single daemon gets its own sandbox, which is a VM whenever possible. Some with network, some without network, different filesystem and vsock access for maximum damage control and minimal trust between daemons. The hypervisor is the most important security boundary to me especially when isolating user-controlled workloads. The more confidence I can get that it is correct the better.
You're responding to a comment where I wrote that I would never use Xen with an argument not to use Xen. All I'm saying is that "formal verification", at least as it exists in current systems, is not why I wouldn't use Xen.
Not my intent but perhaps I communicated poorly. It was an argument that the -reason- Xen has had so many bugs is because it was not built for correctness.
Formal verification should be a bare minimum for a TCB component to know many classes of bugs that have plagued the most popular hypervisors cannot happen.
We both clearly agree not to use Xen.
Anyway, I appreciate the engagement on this all the same.
Yeah, all I'm saying is that I agree with you about Xen, but that I don't agree about the centrality of formal methods --- at least on current projects with current verifications, things could get different now that AI lets us be more ambitious with verification --- in determining attack surface.
Generally, the less your OS can do, apart from strictly hypervising guest operating systems, the safer you probably are. Hence why people do things like seL4.
> the less your OS can do, apart from strictly hypervising guest operating systems, the safer you probably are
100% agreement here and I -would- take something tiny I can audit myself over something huge and formally verified if forced to choose. Thankfully I do not have to choose.
> AI lets us be more ambitious with verification
Exactly. For TCB code formal verification is a minimum, not sufficient, IMO. Too cheap these days to not have very complete test coverage, formal verification, risc0 execution proofs, seccomp tracing. For security critical code we should demand all of it now.
The actual main open source repo has had that warning there for 14 years in spite of commercial forks that are deployed in production government and high risk use cases.
This is one of the most useful web tools I've ever seen.
I work on connectors for datasources (mostly DB's. Being able to quickly test things like sorting behavior and how the same function can be emulated across DB's would have made my life so much easier.
> We can PoC the Firecracker VM Escape on that service.
Does this mean you ran the exploit on your service and confirmed it worked? If so, why would you be advertising this, lol. Unless you've already patched?
This is not a new vulnerability, it's just a description of how to exploit the PwnEscape vulnerability in practice on firecracker VMs (disclosed multiple weeks ago and discussed in some less upvoted posts on HN)
The actual vulnerability got very little discussion. It's clever. Because Linux networking people are obsessed with checksum performance, virtio-net plumbs checksum offload metadata through the host/guest driver interface. Guests can thus deliver the host packets along with instructions on what to checksum. The vulnerability is a missing sanity check that allows checksum instructions to instruct the host to overwrite the header length field in the IPv4 header, rather than the checksum field.
Crucially, this happens in the middle of packet processing, so the kernel code is forced to work with two different ideas of how long the IPv4 header is. All hell predictably breaks loose.
Additional color: per the commit, the bug was found by Paulos Yibelo, who runs PwnAI (the author of this piece), and worked on security at AWS for 4 years prior.
I seem to remember there's a system in place to prevent duplicates (where the submission of a duplicate link results in the upvote of the original story), but maybe that's limited to the first 24h? Idk, HN works in mysterious ways
It's a settled enough part of HN that you'd do better emailing hn@ycombinator.com about it than you will litigating it in public. I don't care either way, I'm just explaining the behavior to you.
I posted a similar query on the Replit sandbox engine article, but..
How do people feel about the hardware isolation provided by microVMs versus the stronger end of software isolation techniques like gvisor?
Right now, we put a huge amount of stock in "hardware isolation". If that starts falling to agents to any substantial degree, I wonder whether we might end up leaning more on patchable software isolation, similar to the rise of software RAID (though, in userspace this time).
My intuition is that gVisor is never going to be stronger in a fair comparison. Almost all the vulns are in I/O code and every type of container/VM/sandbox has I/O.
Running our microVM's inside of a jailed zone, at least gives me some peace of mind.. It's far from perfect, as a zone escape could be lurking.. but at least it's a layer of defense.
As another commenter noted, the PoC in this article doesn't defeat the Firecracker jailer, which does essentially what a "zone" would do for you. In both cases, that's cold comfort, because even in an unprivileged sandbox environment you still have a huge kernel attack surface to contend with LPEs in.
I would've thought that you could actually have an incredibly strict seccomp policy for the jailer which would require you to find an LPE in something like open(2), which seems unlikely even in the "agent swarm" era.
That's basically what the Firecracker jailer does. Always my thoughts turn to the waitid(2) vulnerability; for a little while, you could pass kernel addresses through it and whack arbitrary kernel memory, and nobody was ever going to seccomp "waitid" out. But yes: it's a meaningful defense, if not one you'd want to bet your service on.
Security Exploit requires layering with a Sys Admin Permission Exploit. Nuff said.
This so-called Firecracker exploit never explained how the Guest was able to write to the Host OS's Firecracker user mode process. If the write controlled by the guest to the host was that TCP/IP routing stack Exploit in the host OS's Linux kernel, this Firecracker Exploit is meaningless. The Guest already has unlimited control over the host OS.
I (and anyone) can do this exploit in 2-3 minutes using GDB or Visual Studio's C debugger tool. Freeze process, type new pointers into CPU context snap shot, click resume, Exploit done.
You need something more interesting to say than this, because this is an article by the discoverers of this vulnerability, the first general-purpose Firecracker escape that doesn't depend on nested virtualization in recent memory, along with in-depth discussion of exploitability. It's inherently interesting and on-topic and there isn't an alternate source for the same content.
Informative LLM slop is still LLM slop. We need to insist on high standards of content readability as well as substance. Peer pressure and negative reviews are one way we can influence others.
Not me personally, but with enough social pressure, perhaps these will cease over time. Minority positions become majorities. Policies change. You know, like what happened this past week.
The fact that you’re not joining the call for higher quality content is disheartening.
I really wish they would have expanded on this paragraph in their article further:
> The configuration used here had no jailer. Firecracker's production containment includes dropping privileges and restricting the process through namespaces and seccomp. A deployment using those controls requires a separate assessment of the privileges and resources available after compromising its VMM.
If I'm understanding all of this correctly, a properly jailed and configured firecracker instance would greatly reduce the blast radius of this escape, and I feel as though it would have been good for them to explain what jailing and dropping privileges would do to help. I'd hope most production firecracker deployments would be doing this already.
Not saying that this is any less severe and the root issue is not specific to Firecracker, but to a flaw in the kernel's network code -- they just used an insecure firecracker configuration to demonstrate it. However, I feel like some are taking this as a flaw with firecracker when its not. This is an issue in the kernel networking stack.
That's a good catch. Yes, since they've only proven this up to the jailer boundary, you'd need a second and relatively powerful LPE vulnerability to get real host control out of this.
Thanks to frontier reasoning agents, Linux is completely riddled in ways you can discover 900+ LPE vulnerabilities. [0]
Another wave of vulnerabilities like this are yet to be discovered in Linux. We are just seeing how weak C and C++ based OSes and kernels are when put under hundreds of AI agents.
[0] https://openai.com/index/a-thousand-fewer-paths-to-root/
Watch Hartman’s response to the first wave of issues found by AI. Super dismissive and ignorant.
I’m not sure the people that caused this will be the one fixing it.
you sure the people who caused this (speeding up Linux to mainly serve ads instead of hardening it?) aren't the exact same people now pushing the antidote?
And how many of these vulns are in code for legacy hardware or filesystem support that in no way reflects threats against modern Linux installs? I wager the overwhelming majority of them.
The recent OpenAI release linked above targeted only ~3M SLoC (out of ~40M), core systems code reachable from within a simple VM guest.
We always knew this, it has been understood since nearly the dawn of the monokernel OS that there is always a route to privilege escalation somewhere. This is why even for web applications that would be better served by a shell, people choose CGI-style interfaces instead.
The only reason it wasn't seen as a problem was due to the effort and time it took to find and exploit them.
Nope. The exploit compromises the host kernel. The researchers built an unconventional exploit chain in which they used the host kernel compromise to compromise the host firecracker userspace code, but I see no fundamental reason they couldn't have compromised something else in the host kernel.
Wait, this is also presumably true, come to think of it. I'm a little fuzzy because they document the memory disclosure primitive carefully but not the memory writes they also got from it --- but whatever those are, they're hitting kernel memory? But the exploit they're describing here gets code execution out of Firecracker itself, not the kernel.
AIUI they’ve chosen as their target the host userspace pt_regs, i.e. the kernel structure that stores Firecracker’s register state. If they can find it and write to it, they can control the complete register state of Firecracker.
I assume they chose it as their target because Firecracker, like most Linux KVM userspace [0], maps guest memory into its own address space, giving an easy place to write gadgets.
My personal favorite thing to poke into pt_regs is an actual privileged (CPL0) context. [1] Returning from the kernel right back to a controlled kernel context is allowed by the CPU :)
[0] Until fairly recently this was mandatory. These days it’s possible to ask KVM to map something into the guest without having it in host userspace memory.
[1] Corrupt pt_regs so it executes user memory in kernel mode:
https://seclists.org/oss-sec/2015/q3/291
I think this may be my favorite of all exploits I’ve ever written. In fact, I often made a point of not writing interesting exploits for corruption bugs I found, but this one was too much fun to pass up.
Yeah, they're not saying a lot there. And then the proof of concept code is just being passed the physical addresses of the pages they talk about as command line args, and is just opening /dev/mem to do brain surgery on them.
Which like, isn't really a proof of concept of anything being described.
"That was always allowed".
It's a super good bug! I just don't follow the exploitation details all the way. I know more than one cloud provider panic-bounced their fleet in response to it, and I think that was the right call.
There's for sure a real bug.
It just bothers me that the proof of concept starts with the assumption that host physical memory is mapped into guest physical memory at 2^39. If you can't talk about the actual exploit yet, I get it , but don't write a blog post with something like that called a "proof of concept" when the code shows no exploit, and you're obviously dancing around the actual novel exploit here in the chain. Just keep it in your pants until the disclosure window.
I was reading through and thought "surely I missed a step here" in more than one place.
They mention in part 1 having a write primitive that can hit a 64 byte region, but never really explained how that worked. I'm guessing this was them being able to have checksum offload write TCP/UDP checksum values into the overhang region past the valid data. Maybe the memory map was set up that way, but obviously relies on getting really lucky with getting their page table in the next page after their packet.
Also it was never called out, but as far as I can tell their exploit should only be able to target the beginning of pages for reading/writing. In order to rug-pull the socket logic that reads the IP IHL field, the IP header content needs to be in a page mapped to the guest. The only useful way to use this attack is to have the region spill out of the guest page into whatever page comes next in the kernel's memory map. (Which also makes the mentioning of the skb linear header kind of confusing, since that would be in a completely unrelated kernel memory region, and just have the data pointers pointing into their data, which is what happens for zero-copy network drivers, which presumably was set up for the kvm network for them to retain guest control over the packet.)
The malware infection has been identified as Clang, part of the LLVM threat actor. To clear this infection unlink the directories named /dev and /proc on Ubuntu.
yup, the other firecracker escape recently (https://www.coinspect.com/blog/firecracker-escape/) popped the jailer via io_uring (tl;dr firecracker was filtering syscalls appropriately with seccomp, and was filtering the uring _they_ initiated, so attacker just got them to pop a new unfiltered uring, which is rather nice).
Just for what it's worth, that escape is much more situational than PwnEscape (there have been other escapes that depended on nested KVM, as well). Pretty much everyone seems to have been exposed with PwnEscape, because everyone using Firecracker is also using virtio-net.
I actually do use Firecracker without a network adapter, though vsock/virtio could have remaining issues
> This is an issue in the kernel networking stack.
Exactly, its not a firecracker issue. Using firecracker without a jailer is like setting your password to "password".
Hang on, what are you getting at?
They ran it without a jailer, and exploited a bug in the linux socket code. Firecracker was just how they invoked/worked with /dev/kvm. It is not a firecracker bug. Its sensationalist nonsense.
It's very much a Firecracker thing. KVM is part of the Firecracker stack, and getting code execution behind the jailer is still effectively game-over; it's just a somewhat higher degree-of-difficulty game-over. It's a drastically worse place than you would have been last year, when there wasn't a known plausible way to get even that far.
This is a really good bug and nobody should downplay it.
Huh, so the assertion here that this is a break past the KVM boundary broadly, then?
Also - re: the jailer, do you have more info on that being popped?
The jailer is just a seccomp sandbox. It's not a novel defense system. Sandboxes get broken all the time.
GP said
> They ran it without a jailer
And you said
> getting code execution behind the jailer is still effectively game-over
So I’m really confused, which is it?
Both, maybe? I mean: whether or not they broke the jailer, we know the jailer is breakable; it wouldn't really even be newsworthy to have an LPE that breaks the Firecracker jailer.
Did they break the jailer? I thought from these comments they disabled it.
then the breach happens in KVM? Isn’t KVM its own software repo, and firecracker sits on top? How is this firecracker and not a KvM thing
They C debugging APIs and root permissions in the Host OS to exploit a user mode process in the Host OS. Fire is hot. Water is wet.
I deeply love my idiot comment about not using password for your password generated useful stuff. Kudos to everyone here who rescued my idiocy. Now to change my luggage combination.
[flagged]
Could you please stop posting unsubstantive comments, flamebait, and personal attacks? You've unfortunately been doing these repeatedly, and we ban such accounts.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
sounds like saying it's a Ubuntu thing because you can install firecracker and use kvm to me.
the truth is there plenty more kvm escapes that will be found.
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 letting a huge, complex, and brittle linux kernel and vm ecosystem control the hypervisor layer.
https://hypervisor.org/
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...
Yeah, all security design guarantees are as good as the implementation at the end of the day. All the fancy hashing and encryption math in the world isn't gonna save you from an erroneous `"" == ""` check or an invalid reference check.
I was replying to OP saying it's the same "approach" as Xen, if your preference is "approach" based. It's fair though to point to Nova's smaller code base. It's becoming an important metric for me in general (how big is the code base). It's not a bullet proof thing, but having a smaller code base is a positive sign in 2026 for me.
Novas core seems to be formally verified which rules out a vast amount of bug categories that can happen with xen, including this one
Interesting, I'll have to learn more about Nova.
See Udos most recent talk at 3mdeb Boot Mastery Conference.
He is an ex Intel CPU engineer and the depth of his thought into the security design had me questioning my life choices.
https://youtu.be/RbL65gVzhNk for anyone else looking for it
Thank you. I'll definitely check that out.
having worked with AWS, xen had a lot of very bad vulns over its lifetime as well.
there's no magic.
Now compare to Linux, which is the point raised. Nobody said alternatives like Xen are perfect... but my oh my, some are much better in this regard.
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.
Isn't VMware also that design ?
Xen is formally verified?
No.
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.
Yep, very similar, but L4 is a little bit more general purpose (despite being microscopically tiny) and a little more battle-tested.
Is there a well tested L4 hypervisor solution with hardware accelerated virtualization and raw TPM support formally verified to a similar or greater level than Nova with similar remote attestation and security features?
SeL4 is the closest contender on my radar atm.
Most of the L4s have hypervisor situations. I don't know about TPM support. Generally the vibe I get from systems security people is a bit of eye-rolling about the formal verification of things like L4; the real win is just drastic attack surface reduction.
And then, of course, L4s live in millions and millions of shipped products, which is a reason to consider L4 instead of something novel, but I'm not saying you should or shouldn't.
I for one do not want any code in the TCB that is not formally verified, tiny, and easy to audit with every line of code justified.
SeL4 is the only open, mature, and formally verified L4 solution I am aware of that can run on modern servers, but IIRC given vCPUs are not first class objects and any low level CPU virtualization features are handled in user space, it comes at a real performance cost making it only suitable for single-core or non-performance-critical applications.
Nova by contrast was built to handle the expensive and trust critical TPM and vCPU handling directly for high performance remotely attestable multi-core applications without having to reach for something as heavy as Xen, though formal verification is admittedly not as complete as SeL4 yet AFAICT, though lots of recent progress here.
Those are pretty big tradeoffs, but if you or anyone else knows other viable xen alternatives this general shape with a tiny easily-auditable footprint, please chime in!
Like some of what I'm saying is just that if you tell a systems security person "we're using seL4 because of its formal verification", you're going to get eye rolls. Whatever else you want to say about it, the formally-verified configuration of seL4 doesn't actually do much, meaning whatever system you're building on top of it is going to be where all the security drama is anyways.
I'm certainly not telling you to use Xen. I wouldn't use Xen for anything untrusted.
> the formally-verified configuration of seL4 doesn't actually do much
As a systems security engineer myself I would disagree and know several others that would as well. All depends on your circles, applications, and threat model I suppose.
Xen, Hyper-V, and KVM have all had major security flaws in the form of logic violations, spacial memory corruptions, use-after-free, and pointer corruptions that allowed hypervisor trust boundary violations. I expect most if not all of those classes of bugs could have been prevented by formal verification.
Xen likely has a bad reputation with both of us because of a history of preventable flaws like these.
In my applications every single daemon gets its own sandbox, which is a VM whenever possible. Some with network, some without network, different filesystem and vsock access for maximum damage control and minimal trust between daemons. The hypervisor is the most important security boundary to me especially when isolating user-controlled workloads. The more confidence I can get that it is correct the better.
You're responding to a comment where I wrote that I would never use Xen with an argument not to use Xen. All I'm saying is that "formal verification", at least as it exists in current systems, is not why I wouldn't use Xen.
> an argument not to use Xen
Not my intent but perhaps I communicated poorly. It was an argument that the -reason- Xen has had so many bugs is because it was not built for correctness.
Formal verification should be a bare minimum for a TCB component to know many classes of bugs that have plagued the most popular hypervisors cannot happen.
We both clearly agree not to use Xen.
Anyway, I appreciate the engagement on this all the same.
Few even know alternatives to xen exist!
Yeah, all I'm saying is that I agree with you about Xen, but that I don't agree about the centrality of formal methods --- at least on current projects with current verifications, things could get different now that AI lets us be more ambitious with verification --- in determining attack surface.
Generally, the less your OS can do, apart from strictly hypervising guest operating systems, the safer you probably are. Hence why people do things like seL4.
> the less your OS can do, apart from strictly hypervising guest operating systems, the safer you probably are
100% agreement here and I -would- take something tiny I can audit myself over something huge and formally verified if forced to choose. Thankfully I do not have to choose.
> AI lets us be more ambitious with verification
Exactly. For TCB code formal verification is a minimum, not sufficient, IMO. Too cheap these days to not have very complete test coverage, formal verification, risc0 execution proofs, seccomp tracing. For security critical code we should demand all of it now.
> 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 has had that warning there for 14 years in spite of commercial forks that 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.
What's the OS ?
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.
I work on connectors for datasources (mostly DB's. Being able to quickly test things like sorting behavior and how the same function can be emulated across DB's would have made my life so much easier.
> We can PoC the Firecracker VM Escape on that service.
Does this mean you ran the exploit on your service and confirmed it worked? If so, why would you be advertising this, lol. Unless you've already patched?
This is not a new vulnerability, it's just a description of how to exploit the PwnEscape vulnerability in practice on firecracker VMs (disclosed multiple weeks ago and discussed in some less upvoted posts on HN)
> already discussed at length on HN
Couldn't find it. Care to provide link.
The actual vulnerability got very little discussion. It's clever. Because Linux networking people are obsessed with checksum performance, virtio-net plumbs checksum offload metadata through the host/guest driver interface. Guests can thus deliver the host packets along with instructions on what to checksum. The vulnerability is a missing sanity check that allows checksum instructions to instruct the host to overwrite the header length field in the IPv4 header, rather than the checksum field.
Crucially, this happens in the middle of packet processing, so the kernel code is forced to work with two different ideas of how long the IPv4 header is. All hell predictably breaks loose.
That’s fascinating. I’ve seen this sort of thing on protocol implementations in layer 4+ but it’s rare to find it in layer 3.
Fixed a month ago upstream
https://github.com/torvalds/linux/commit/6785011f8b16abf40b1...
https://www.pwn.ai/blog/pwnescape
Additional color: per the commit, the bug was found by Paulos Yibelo, who runs PwnAI (the author of this piece), and worked on security at AWS for 4 years prior.
OP asked for a link
And honestly, how the &*DK is this ANYTHING related to firecracker?
Ah maybe not on HN, I forget where I learned of it. Either way, multiple weeks ago: https://news.ycombinator.com/item?id=50108845
Dupe: https://news.ycombinator.com/item?id=50381397
(Doesn't HN usually deduplicate links? I'm confused)
Duplicates are generally accepted when there was no significant discussion on the original submission.
I seem to remember there's a system in place to prevent duplicates (where the submission of a duplicate link results in the upvote of the original story), but maybe that's limited to the first 24h? Idk, HN works in mysterious ways
This has negative impact on searching older discussions. Instead of 1 result for 1 URL (within few month) getting 2 or even more.
It's a settled enough part of HN that you'd do better emailing hn@ycombinator.com about it than you will litigating it in public. I don't care either way, I'm just explaining the behavior to you.
I posted a similar query on the Replit sandbox engine article, but..
How do people feel about the hardware isolation provided by microVMs versus the stronger end of software isolation techniques like gvisor?
Right now, we put a huge amount of stock in "hardware isolation". If that starts falling to agents to any substantial degree, I wonder whether we might end up leaning more on patchable software isolation, similar to the rise of software RAID (though, in userspace this time).
My intuition is that gVisor is never going to be stronger in a fair comparison. Almost all the vulns are in I/O code and every type of container/VM/sandbox has I/O.
FYI, gvisor also uses KVM under the hood; it's not completely orthogonal to [micro]VMs.
That's not the default gvisor option. It can use kvm, but by default (and most common setup in my limited experience) it doesn't.
You mean virtualised hardware ? That's still technically software
I've been building Firehyve, which is a firecracker like microVM solution for illumos and FreeBSD.. https://github.com/TritonDataCenter/rshyve
Running our microVM's inside of a jailed zone, at least gives me some peace of mind.. It's far from perfect, as a zone escape could be lurking.. but at least it's a layer of defense.
As another commenter noted, the PoC in this article doesn't defeat the Firecracker jailer, which does essentially what a "zone" would do for you. In both cases, that's cold comfort, because even in an unprivileged sandbox environment you still have a huge kernel attack surface to contend with LPEs in.
I would've thought that you could actually have an incredibly strict seccomp policy for the jailer which would require you to find an LPE in something like open(2), which seems unlikely even in the "agent swarm" era.
That's basically what the Firecracker jailer does. Always my thoughts turn to the waitid(2) vulnerability; for a little while, you could pass kernel addresses through it and whack arbitrary kernel memory, and nobody was ever going to seccomp "waitid" out. But yes: it's a meaningful defense, if not one you'd want to bet your service on.
Security Exploit requires layering with a Sys Admin Permission Exploit. Nuff said.
This so-called Firecracker exploit never explained how the Guest was able to write to the Host OS's Firecracker user mode process. If the write controlled by the guest to the host was that TCP/IP routing stack Exploit in the host OS's Linux kernel, this Firecracker Exploit is meaningless. The Guest already has unlimited control over the host OS.
I (and anyone) can do this exploit in 2-3 minutes using GDB or Visual Studio's C debugger tool. Freeze process, type new pointers into CPU context snap shot, click resume, Exploit done.
https://aws.amazon.com/security/security-bulletins/2026-137-...
This is pure LLM slop.
You need something more interesting to say than this, because this is an article by the discoverers of this vulnerability, the first general-purpose Firecracker escape that doesn't depend on nested virtualization in recent memory, along with in-depth discussion of exploitability. It's inherently interesting and on-topic and there isn't an alternate source for the same content.
Informative LLM slop is still LLM slop. We need to insist on high standards of content readability as well as substance. Peer pressure and negative reviews are one way we can influence others.
You can't insist your way through not learning about one of the most important vulnerabilities announced in the last 50 days.
You’re posing a false choice. I can learn it and still insist that people communicate well.
I mean, it's good to want things, but I don't know what that gets you today. They're not going to give you the hand-crafted post you're asking for.
Not me personally, but with enough social pressure, perhaps these will cease over time. Minority positions become majorities. Policies change. You know, like what happened this past week.
The fact that you’re not joining the call for higher quality content is disheartening.
Hey, I don't write AI blog posts. But I want to know how KVM escapes work, too.
You don't because you consider KVM to be part of Firecracker?
If you're a provider, you absolutely do; it's part of the stack. It's like saying "Ruby" isn't a part of "Rails".
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.
Firecracker v1.17.0 was released 10 September, so the version is ancient.
Do you even know what ancient means? 2 months is ancient for you? Are you like 6?
Yes, 2 months is ancient if 0 days is the game.
Fly uses it too afaik
Basically everyone in cloud-land uses it at this point.
And should jail/SE.
Not affected https://aws.amazon.com/security/security-bulletins/2026-137-...
The article is light on details, it is LLM slop.
it's really informative. At least someone are break it.