We really need a properly written open source hypervisor: entities using secure hypervisors commercially like Amazon AWS should fund the development of one.
Xen was actually written with security in mind, they push as much of the features and driver code out of the hypervisor and onto Dom0 as possible to minimize the attack surface in the hypervisor itself.
Source - The Definitive Guide To Xen - 2007.
Because that should be considered a security hole. Knowing the attack surface is there is, in this context, a security bug in and of itself, because it implies there is already an attack, or an attack is forthcoming.
Unless it's possible to run an unmodified Xen as a guest under Xen, the project is incomplete.
If the kernel itself doesn't just straight up say it's a kernel designed to work under Xen the drivers used to work with the virtualization will give it away. Right down to the version if you care to dig deep enough and compare builds.
http://www.brendangregg.com/blog/2014-05-09/xen-feature-dete...
What makes this bug a huge deal for me, and probably why it's making the news is that it effects fully paravirtualized guests. There have been many, many bugs for HVM guests (and for KVM guests) since the last PV security hole. (March, was it? xsa-123, I think?)
A PV VM would use hypercalls instead of regular system calls, would have more context switches due to the lack of protection rings, etc.
It's inferior in basically every way to HVM. CPU performance is worse due to missing protection rings on x86_64, PV drivers for disk and network bring HVM performance to PV for those, SR-IOV for networking makes networking faster, other hardware extension make memory access faster...
THere's very very very very very few workloads that perform better on PV than HVM.
https://rhn.redhat.com/errata/RHSA-2015-1896.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456
I could go on and on and on... but the point is that kvm (and xen HVM mode) may have performance advantages in some situations, but xen pv mode has consistently had fewer security vulnerabilities, especially if you use something like pv-grub to load untrusted guest kernels (rather than loading those kernels directly in the dom0)
The biggest problem is the qemu drivers; Honestly, I don't know enough about kvm to know if it was possible, but if you could completely remove the device emulation and force the guest to only use paravirtualized drivers, your security under KVM (or Xen HVM) would be much better, mostly because you'd vastly reduce the amount of hypervisor code the guest interacts with.
But the point here is that all systems have problems, and the xen pv mode has had fewer security holes found it it than most other hypervisors, mostly because there's a lot less code that the guest interfaces with.
s/may/certainly s/some/almost all
It's not a small gap, either. You are basically doubling the number of context switches required for system calls with PV, due to AMD removing CPU protection rings from x86_64, forcing this separation to have to happen in software. You lose out on EPT, so your page table performance suffers in almost all workloads. You cannot take advantage of SR-IOV for NICs or nvme.
PVH might be an answer someday, but for now, there is a pretty massive performance loss. Context switches are important. Memory latency is important. (Nearly) direct access to the hardware is important.
x86 is a nasty enough architecture on its own. x86 plus hypercalls is even nastier and, even more importantly, x86 plus hypercalls is differently nasty.
The current bug is pv-specific. there was another one that effected me early this year[1]... I'm not saying it's bug free or anything, I'm just saying that xen PV has had fewer exploits over the last year (and over the last decade) than HVM mode or KVM.
[1]xsa123 if I remember right; my blog archive is all messed up at the moment. but, for example, xsa-108, which was a big deal, was a non-issue for me because all my stuff is paravirtualized.
Note, the list I'm going off of is here: