Explo-Xen! Bunker buster bug breaks out guests from hypervisor A super-bug in the Xen hypervisor may allow privileged code running in guests to escape to the underlying host. This means, on vulnerable systems, malicious administrators within virtual machines can potentially break out of their confines and start interfering with the host server and other guests. This could be really bad …
The following statement is wrong!
> The bug was discovered by Jérémie Boutoille of Quarkslab, and publicly
> patched on Tuesday for Xen versions 4.5 to 4.7 and the latest
> bleeding-edge code.
Patches are available for
xsa182.patch [for] xen-unstable, Xen 4.7.x
xsa182-4.6.patch [for] Xen 4.6.x
xsa182-4.5.patch [for] Xen 4.5.x, 4.4.x, 4.3.x
From what I can see the Qubes project contribute nearly sqrt(F-all) to the upstream project they depend on (Xen).
So they don't like Xen, either
1) Shut up and contribute code
2) Switch in KVM if it's so easy
3) Write their own hypervisor - both FreeBSD and OpenBSD have done this (although OpenBSD haven't shouted about it much, and it's a tad less functional than other implementations). These, and KVM, are type 2 hypervisors though, whilst Xen is type 1 (it will run on bare metal without a kernel, and there are a choice of dom0 kernels. Note that FreeBSD current is now dom0 capable, although there's no passthrough yet)
Indeed. Looking at Qubes project security bulletins, they often appear to be designed to create maximum publicity for Qubes. When you look at their Xen critique from November last year, Qubes raised a number of points, and then failed to engage further. I am not aware of any other project/vendor who uses security bulletins in this way.
I also find the following portion of this Qubes security bulletin revealing: "A more radical reader might be of the opinion that we should completely replace Xen with some other hypervisor. Such an opinion is surely not unfounded, as we have previously expressed our disappointment in the Xen security process [5]. Sadly, not much has improved over the past several months. Moreover, even though Qubes is now based on a hypervisor-abstracting architecture ("Odyssey"), which should make switching to a different VMM a relatively easy task, the primary problem that remains is the lack of a good alternative hypervisor to which we could move [6]."
So in other words, every alternative available is worse, in the view of the Qubes team. But of course this is not covered in this story
I do not use KVM but did not believe the claim that it is a type 2 hypervisor, did a quick search and came up with
https://www.ibm.com/developerworks/community/blogs/ibmvirtualization/entry/kvm_myths_uncovering_the_truth_about_the_open_source_hypervisor?lang=en
"Myth #1: KVM is type 2 hypervisor that is hosted by the operating system, and isn’t a bare metal hypervisor.
This is a persistent myth, but the truth is that KVM actually does run directly on x86 hardware. People assume it is a type 2 hypervisor because one of the ways that it is packaged is as a component of Linux - so you can be running a Linux distribution and then, from the command-line shell prompt or from a graphical user interface on that Linux box, you can start KVM. The interface makes it look like it is a hosted hypervisor running on the operating system, but the virtual machine is running on the bare metal - the host operating system provides a launch mechanism for the hypervisor and then engages in a co-processing relationship with the hypervisor. . In a sense, it is taking over part of the machine and sharing it with the Linux kernel."
I assume the misconception is similar for those people that think Vmware ESX/ESXi runs on top of linux because they see linux messages on bootup.
(Vmware customer since 1999 - haven't seen anything in Xen or KVM that has gotten me interested in evaluating them as alternatives - Linux user since 1996 so not like I don't have experience with open source stuff)
It's a persistent misconception because it's true. KVM cannot be run without Linux. Xen can, and is, run without Linux. There's the well known kernels (Linux, Solaris and derivatives, NetBSD), the in progress (FreeBSD) and the custom (MiniOS, shipped as an example with Xen, and third party options).
I've just checked the documentation for RHEV, and it's clearly a stripped down Linux. At one point KVM.ko did load under FreeBSD, but that's only because of FreeBSD's Linux compatibility, and even then it didn't work well.
Personally I think of KVM as an optional Qemu accelerator, coupled with some excellent pci passthrough tools. Xen's paravirtualised architecture means it can be quite different, and it's (in my opinion), considerably better integrated than KVM, plus has a (now free) turnkey system using a custom Linux distribution, looking not dissimilar to ESXi.
Obviously there's also the cost, and supportability issues. VMWare is excellent, but will cost a lot in some configurations, has a limited set of supported hardware, and most irritating keeps dropping support for perfectly functional hardware in new releases. At least with Xen/KVM, it's using standard OS drivers.
Bit of a cheeky one there, IMO.
Given that I couldn't write a VM to save my life, I think that Xen has some pretty damn good programmers.
Nobody's perfect, of course, but VM programming seems to me to be especially difficult. With any application, new security holes are regularly discovered. Some of them are trivial. With VMs there have been, to my knowledge, no trivial exploits.
That's not bad right there, in my book.
You'd be right there. There's plenty of workarounds for duff hardware, and at least on the KVM side (probably Xen too) some features are based on whitelists and blacklists. i.e. Intel and AMD have told the virtualisation project that a particular chipset supports this feature, but it's not discoverable, so it has to be enabled/disabled based on PCI IDs, etc.
The number of BIOSes with fully or partially broken ACPI or DMAR tables is huge, and outside server boards, vendors don't tend to care as VT-d has been a rarely used feature on consumer kit until recently, and ACPI anomalies can often be worked around. Solutions include 'buy a new motherboard' or workarounds such that the ACPI/DMAR tables work, but only when certain devices are enabled/disabled (i.e. the BIOS does not correctly modify the tables based on installed devices, as it should).
BIOSes have done a lot more than load a boot sector, for a very long time.
"Not that I'm an expert, but as a general principle I would expect that the "hardware" features used to implement hypervisors are likely to have at least as many bugs."
Few people appear to pay attention to the Errata sheets published by CPU vendors, you could become an expert on the topic if you read a couple of them. :)
I suspect folks who have read those errata sheets and who are serious *serious* about securing their hardware they would give things like hypervisors and x86 hardware a miss and maybe looked for something a bit easier to lock down.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
