VMScape and why Xen dodged it

Summary

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:VMScape: Exposing and Exploiting Incomplete Branch Predictor Isolation in Cloud Environments – Computer Security GroupIt’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 affectedThe 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...