VMScape and why Xen dodged it
It’s been less than two weeks since the security team at ETH Zürich published their research on a new microarchitectural attack they call VMScape:
Skip to content
It’s a neat piece of work, and it shows once again how CPUs, with all their clever tricks for performance, can sometimes open the door to data leaks across virtual machines.
What is VMScape?
The short version: modern CPUs use a branch predictor to guess where code will go next. It makes things faster, but the predictor also “remembers” past patterns. If you can manipulate that memory, you can mislead the CPU and peek at things you shouldn’t. That’s the basic idea behind Spectre-style attacks.
According to the ETH team:
“We find that branch predictor state is not fully flushed across VMs, enabling cross-VM Branch Target Injection (vBTI) primitives. We demonstrate the practical impact of vBTI with VMScape, a cross-VM attack capable of leaking QEMU userspace secrets from a malicious guest VM on AMD Zen 4 and Zen 5 CPUs.”
In other words, a malicious VM can target the hypervisor’s userspace components and start leaking data. For KVM, that means QEMU, which is heavily exposed. VMware is in the same situation.
Why Xen wasn’t affected
The researchers also note that Xen is not vulnerable. That’s not because Xen has no bugs (it does, like every hypervisor), but because of its architecture.
From day one, Xen was designed to keep the hypervisor core small and move everything else out. Device emulation, storage drivers, network stacks — they all live in Dom0, which is itself just another virtual machine. Dom0 has more privileges than a normal guest, but it’s still not the hypervisor.
That architectural choice makes Xen closer to a microkernel than a traditional monolithic hypervisor. The core stays minimal, with a narrow set of responsibilities, and anything that doesn’t absolutely need to run at the highest privilege level gets pushed out. That’s not just elegant — it’s a big deal for security.
Size matters (in a good way)
Because the hypervisor itself is small, it’s easier to audit, reason about, and even certify. That’s why you’ll find Xen at the heart of a lot of embedded and safety-critical projects, where formal verification and certification are required. Try doing that with a massive, monolithic kernel and you’ll quickly run into a wall. With Xen, it’s actually feasible (and being done as we speak).
VMScape highlights the benefits of that design: QEMU is simply not sitting next to the hypervisor. Even if you leak information from it, you’re still only talking about a process in Dom0, not the privileged heart of the system.
Why this matters
Architectural choices made twenty years ago are paying off today. By separating responsibilities, Xen reduced its attack surface and avoided a whole class of problems. That doesn’t make it invincible (Xen has had and will have its share of vulnerabilities) but it does mean that by design, certain attacks don’t land as hard.
As the ETH Zürich team points out, mitigations for KVM involve adding new predictor flushes, which Linux developers have already started to implement. VMware will need similar patches. Xen doesn’t need those same emergency measures, because the architecture already put a buffer in place.
Defense in depth
It’s tempting to say “Xen wins” and stop there. But that’s not the whole story. Security is never just about one design decision. CPUs will keep evolving, new side channels will keep appearing, and no hypervisor can afford to be complacent.
Still, VMScape is a good reminder that defense in depth starts at the architecture level. A small, microkernel-like core, privilege separation, isolation of device emulation — all of that adds resilience. It won’t stop every possible attack, but it does add another layer of safety, and in security, layers are what make the difference.
Member discussion