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.
This is different from KVM where your hypervisor runs in your Dom0/Root Partition.
Anyone considering Xen should probably also consider Nova depending on requirements.
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.
He is an ex Intel CPU engineer and the depth of his thought into the security design had me questioning my life choices.
there's no magic.
SeL4 is the closest contender on my radar atm.
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.
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!
I'm certainly not telling you to use Xen. I wouldn't use Xen for anything untrusted.
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.
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!
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.
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.
To save people the time:
"This code is experimental and not feature complete. If it breaks, you get to keep both pieces."
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.