Slashdot Mirror


Xen Patches 7-Year-Old Bug That Shattered Hypervisor Security (arstechnica.com)

williamyf writes: ArsTechinca, The Register, and other outlets are reporting that today the XEN project patched a vulnerability in the ParaVirtualized VMs that allowed a guest to access the control OS of the hypervisor. Qubes researchers wrote: "On the other hand, it is really shocking that such a bug has been lurking in the core of the hypervisor for so many years. In our opinion the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again".

8 of 61 comments (clear)

  1. XEN PV mode is dead by Anonymous Coward · · Score: 5, Interesting

    The truth is nobody uses para-virtualized VMs anymore. EC2 which was the last bastion for pv xen stopped using it a couple of years ago and moved entirely to hvm model. I'm not even sure that the latest Linux kernel support are compiled with Xen PV support. If you looked at the kernel code for PV XEN support you know what the mess that was so good riddance. You need to understand what PV mode means for hypervisors: a kernel must be specifically modified to talk to a hypervisor so instead of performing a privileged CPU instruction it would call a Hypervisor provided function. I'm sure there were tons of security issues with that approach and many still exists. Anyway PV model is not relevant anymore since Intel introduced hardware virtualization on the CPU. It was introduced to to improve perfromance of VMs but it's not relevant anymore

    1. Re:XEN PV mode is dead by engun · · Score: 2

      PV and HVM are not mutually exclusive. The basic idea of having a modified, "virtualization-aware" guest-os (a.k.a PV) is a good one and results in better performance. Hardware Virtualization often simplifies the implementation of both the hypervisor and PV on the guest, but does not obviate the need for PV. Using both in tandem can result in even greater performance gains. http://wiki.xen.org/wiki/PV_on...

    2. Re:XEN PV mode is dead by TheRaven64 · · Score: 2

      You probably want to link to PVH, not PVHVM for the real relevant approach. That said, HVM usually implies, at a minimum, hardware support for nested page tables. The bug in question is only present when using shadow page tables. Even if you're using PV devices in an HVM or PVH VM, you're using the hardware page tables.

      --
      I am TheRaven on Soylent News
  2. With enough Eyes.. Blah Blah Blah by williamyf · · Score: 2

    ESR Was wrong. Enough Eyes are not enough!

    One needs Enough QUALIFIED AND MOTIVATED eyes, as well as proper test cases, a Quality Assurance group and Technical Guidelines.

    --
    *** Suerte a todos y Feliz dia!
  3. Bugs happen, even in hypervisors by martyros · · Score: 2

    Go do LWN's search page, uncheck all the boxes except for "security vulnerabilities", and then search for "KVM". Or Qemu, or Linux or Xen.

    You'll find that all hypervisors have privilege escalation bugs discovered. However, this is the first one discovered in the Xen PV interface in a long time.

    --

    TCP: Why the Internet is full of SYN.

  4. Re:Bug in English by CurryCamel · · Score: 2

    that would not let similar flaws to plague the hypervisor ever again

    Can we trust people to critique code who can't even manage English grammar?

    Yes. Very few program is written in English. C is more common.

    And looking at the Qubes OS team https://www.qubes-os.org/team/, I'd bet English isn't the primary language for most of them.

  5. Misunderstanding ESR. Shallow, not non-existent by raymorris · · Score: 4, Insightful

    ESR didn't say "given enough eyeballs, no bugs exist."
    He said they are -shallow-. "The fix will be obvious to someone". That is, you won't spend a month trying to to figure out exactly why foo sometimes conflicts with widget - with with several people looking at the source (not just the output of the binary), someone will more quickly see why foo conflicts with widget and how to fix it.

    It looks like in this case it was about 48 hours or so to characterize the problem, agree on the proper fix, code it, test, patch the major public clouds, and release it publicly. Guessing that patching the public clouds took 24 hours, that's about 24 hours for understanding the problem, discussing it fixing it, and testing. Not bad. Here's a quote from CATB with the context of the "bugs are shallow" part:

    ---- ... if any serious bug proved intractable. Linus was behaving as though he believed something like this:

    8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

    Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.

    My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it.

    ----

    It's about bugs not being intractable - they aren't extremely hard to figure out, "the fix will be obvious to someone". That doesn't mean they never existed.

  6. Re:Classic Open Source by goarilla · · Score: 2

    The Qubes OS people do participate in Xen's development (http://xenbits.xen.org/gitweb/?p=xen.git&a=search&h=HEAD&st=commit&s=marek).