4 ms·

just in October: https://rhn.redhat.com/errata/RHSA-2015-1896.html https://rhn.redhat.com/errata/RHSA-2015-1896.html http://cve.mitre.org/cgi-bin/cvename.cgi?

by lsc 11y ago

just in October: https://rhn.redhat.com/errata/RHSA-2015-1896.html https://rhn.redhat.com/errata/RHSA-2015-1896.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456 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.

cthalupa 11y ago
>may have performance advantages in some situations 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.
- lsc 11y ago
  I'm not saying you are wrong about performance (other than to point out that actually using the qemu devices is even slower.) Still, if you go through the xsa list, if I was running HVM, I'd have had to reboot pretty often. It's a huge firedrill every time the security list sends something out, for those of us who use (normally lower-stress) local disk. Twice in one year is bad enough.
  - cthalupa 11y ago
    Well, yeah, software emulated hardware is slow, but no one should be using emulated PCI devices on anything. There are PV or better yet, SR-IOV drivers that can be used for those that are going to be the closest to bare metal performance you'll get in a VM.
amluto 11y ago
As a kinda-sort-maintainer of a bunch of the low-level Linux code that is all tangled up with the Xen PV stuff, I would be shocked if there isn't a PV-specific security bug or two in there. 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.
- lsc 11y ago
  > As a kinda-sort-maintainer of a bunch of the low-level Linux code that is all tangled up with the Xen PV stuff, I would be shocked if there isn't a PV-specific security bug or two in there. 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: http://xenbits.xen.org/xsa/ http://xenbits.xen.org/xsa/