QEMU may be fro-Xen out after two new bugs emerge The Xen project has revealed another two bugs in the QEMU hypervisor and is now wondering the extent to which it should support the buggy code. The first of the flaws, CVE-2015-5165, means “A guest may be able to read sensitive host-level data relating to itself which resides in the QEMU process” and impacts “All Xen systems …
Unfortunately, this article has got the wrong end of the stick. "qemu-xen-traditional" is a forked/patched version of qemu that is currently maintained by the Xen project. Newer versions of Xen now work with the uptream version of qemu. That comment is basically saying.... "Isn't it time we ditched our old forked/patched version, as it's too onerous to maintain it now". I don't see anything to suggest that the usage of the upstream version is going to be ditched.
If it was a huge problem with qemu, it'd be more an issue for KVM, because that can't work without qemu (it's a qemu accelerator). Xen only uses qemu to provide devices.
There is an issue here - the upstream qemu is not as stable as qemu-traditional, especially if you're running physical device passthrough to the VM.
Whilst Xen isn't a bad product, there's the unfortunate tendency to deprecate older code before the newer code contains the same functionality. I hope this doesn't happen to qemu-traditional; I suspect most Xen users would be happy to move to upstream when it's feature complete. With Xen 4.5 the xm management tool has been removed, which is unfortunate because xl does not yet quite provide all the same facilities (fortunately the missing parts are less commonly used).
I am sure if someone offered to backport (or pay someone to backport it) the fix to traditional, it would still be accepted, though. Same goes for the development of any missing functionality in xl. My experience of the Xen custodians is that if someone puts forward something with merit and is prepared to write it, then they will include it.
I'm sure they would, but they don't have a lot of choice here - older versions of Xen are in active use, still supported, and have to be maintain security. Also, qemu-traditional has a direct impact on how well various HVM domains are supported - I'd love to run upstream, but experience shows various weirdness in a variety of operating systems if I use it, that doesn't exist in -traditional.
xl is less of an issue - the two things which stick out are USB support, and floppy disks, possibly others that I forget, too. The USB issue can be worked around, as can floppies - it took the abnormal use case of installing an old OS to discover that.
> The advisory for the flaw also offers the following contentious text:
>
> “We will encourage the community to have a conversation, when this advisory is
> released, about the continuing security support status of qemu-xen-traditional in
> non-stub-dm configurations.”
I can see how this text could be seen as contentious, but it is everything but. Xen ships with two versions of QEMU (see https://blog.xenproject.org/2013/09/20/qemu-vs-qemu-traditional-update/). So what this statement really means, is that the Xen Project should have a discussion to deprecate the qemu-xen-traditional fork in favour of QEMU upstream. This would mean that security fixes do not have to be backported from QEMU upstream to qemu-xen-traditional.
> With another two similar flaws now revealed, little wonder the Xen community is
> pondering its future relationship with QEMU.
Although split-ups do make a nice story, the opposite is actually the case. The Xen Project is working closer than ever with the QEMU folks and deprecation of our old qemu-xen-traditional fork is a sign of that growing closeness. In addition, we are working more closely on the security front too: the fact that Xen is handling more QEMU issues jointly with the QEMU security team is also a reflection of that. We also have some joint activities planned at LinuxCon.
Granted that the recent number of QEMU issues has been painful, but after Venom, it was to be expected that this would happen. And many of these issues also affect other consumers of QEMU (e.g. KVM). To mitigate such issues in the future, work is underway to sandbox QEMU within Xen (google for "xsrestrict QEMU", http://lists.xen.org/archives/html/xen-devel/2015-07/msg04501.html, ... ) such that the impact of future issues with QEMU can be contained.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
