back to article 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 …

  1. Anonymous Coward
    Anonymous Coward

    Wrong end of the stick

    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.

  2. BinkyTheMagicPaperclip Silver badge

    What the anonymous coward said

    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).

    1. MrMur

      Re: What the anonymous coward said

      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.

      1. BinkyTheMagicPaperclip Silver badge

        Re: What the anonymous coward said

        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.

  3. larsk

    > 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 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",, ... ) such that the impact of future issues with QEMU can be contained.

    1. justincormack

      Also there is a plan to make stubdoms for qemu standard not exceptional, which would mitigate all the issues, as you just get access to another domain you cant do anything in, rather than qemu running in dom0.

  4. larsk

    The problem with stubdoms is that they affect the bottom line of hosting/cloud providers. So even if Xen were to enable them by default, hosting/cloud providers would probably disable them. That's why an alternative is being worked on.

  5. lara

    xen run on qemu


    i want to run xen on there options (in qemu) that allow me to run xen with dom0 and domu on qemu ..( like -kernel and -initrd when we run the linux kernel ) ... or any other method may help me

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like