4 ms·

The existence of such a catastrophic bug shows that Xen is unfortunately not suitable for use as an hypervisor in a secure system and needs to be replaced. We

by devit 11y ago

The existence of such a catastrophic bug shows that Xen is unfortunately not suitable for use as an hypervisor in a secure system and needs to be replaced. We really need a properly written open source hypervisor: entities using secure hypervisors commercially like Amazon AWS should fund the development of one.

toomuchtodo 11y ago
Is KVM not a "properly written open source hypervisor"?
- esaym 11y ago
  As long as you don't need PV...
  - nly 11y ago
    PV = paravirt? Because there are virtio drivers for Windows. KVM qualifies as paravirtualisation to me.
    - cthalupa 11y ago
      KVM is not paravirtualization - it has paravirtualized drivers. A PV VM would use hypercalls instead of regular system calls, would have more context switches due to the lack of protection rings, etc.
  - cthalupa 11y ago
    Why would you need PV? 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.
    - esaym 11y ago
      PV at least at one time, was more efficient than emulating straight hardware. And PV was the only way you could run visualization on Intel Atom since the first batches did not have the hardware bits needed for KVM.
- 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.
click170 11y ago
Did you know that AWS uses their own version of Xen? 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.
- cbd1984 11y ago
  Is it possible to tell whether you're running under Xen? 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.
  - AReallyGoodName 11y ago
    For PV it's quite easy. 'uname -a' is currently straight up telling me i'm on the el5xen PV kernel. 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.
    - cthalupa 11y ago
      It's trivial on HVM as well http://www.brendangregg.com/blog/2014-05-09/xen-feature-detection.html http://www.brendangregg.com/blog/2014-05-09/xen-feature-dete...
notabot 11y ago
Please define "properly written" then we can discuss who is going to fund it.
- lmm 11y ago
  I no longer believe it's possible to write code properly in C (not that it's easy in other languages). Which for a hypervisor probably means waiting for Rust.
  - andrewchambers 11y ago
    This bug has nothing to do with the properties of C. Rust wouldn't have helped.
  - ngrilly 11y ago
    What makes you think Rust would have helped in this specific case?
lsc 11y ago
> The existence of such a catastrophic bug shows that Xen is unfortunately not suitable for use as an hypervisor in a secure system and needs to be replaced. 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?)

by devit 11y ago

toomuchtodo 11y ago

Is KVM not a "properly written open source hypervisor"?

esaym 11y ago
As long as you don't need PV...
- nly 11y ago
  PV = paravirt? Because there are virtio drivers for Windows. KVM qualifies as paravirtualisation to me.
  - cthalupa 11y ago
    KVM is not paravirtualization - it has paravirtualized drivers. A PV VM would use hypercalls instead of regular system calls, would have more context switches due to the lack of protection rings, etc.
- cthalupa 11y ago
  Why would you need PV? 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.
  - esaym 11y ago
    PV at least at one time, was more efficient than emulating straight hardware. And PV was the only way you could run visualization on Intel Atom since the first batches did not have the hardware bits needed for KVM.
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.

click170 11y ago

Did you know that AWS uses their own version of Xen? 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.

cbd1984 11y ago
Is it possible to tell whether you're running under Xen? 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.
- AReallyGoodName 11y ago
  For PV it's quite easy. 'uname -a' is currently straight up telling me i'm on the el5xen PV kernel. 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.
  - cthalupa 11y ago
    It's trivial on HVM as well http://www.brendangregg.com/blog/2014-05-09/xen-feature-detection.html http://www.brendangregg.com/blog/2014-05-09/xen-feature-dete...

notabot 11y ago

Please define "properly written" then we can discuss who is going to fund it.

lmm 11y ago
I no longer believe it's possible to write code properly in C (not that it's easy in other languages). Which for a hypervisor probably means waiting for Rust.
- andrewchambers 11y ago
  This bug has nothing to do with the properties of C. Rust wouldn't have helped.
- ngrilly 11y ago
  What makes you think Rust would have helped in this specific case?

lsc 11y ago

> The existence of such a catastrophic bug shows that Xen is unfortunately not suitable for use as an hypervisor in a secure system and needs to be replaced. 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?)