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.
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.
[dead]
> 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 ?
[flagged]
That phrase predates LLMs.
Considering the commit that added that text was 14 years ago, I am going to assume it was written by a human.
https://github.com/udosteinberg/NOVA/commit/9e35d89c0e7014f1...