Security around Xen, XenServer and QEMU

Olivier Lambert

• 3 min read

You probably heard a lot of stories lately around security concerns from QEMU flaws impacting Xen. Let's take the time to understand what is really going on. We'll see first what about Xen project and also XenServer.

Xen guest types

Because it always confuses people, I'll take the time to racap the list of possible guest (virtual machine) types, or Modes in Xen:

  • HVM
  • PV
  • PVHVM
  • PVH

For a more complete reading, you can check my blog post, this article on the Virtualization Spectrum or this page about Xen overview.

Xen was originally built to run PV guests. In PV mode, your guest OS "knows" it's running on top of an hypervisor (the guest kernels is modified to use the right hypercalls). Sadly, this is not possible with every systems.

So, it comes the need for emulation. And what tool to use for that? You get it: QEMU.

QEMU

QEMU (short for Quick Emulator) is a free and open-source hosted hypervisor that performs hardware virtualization (Wikipedia).

In the Xen HVM mode, QEMU is here to emulate disks, network, motherboard and PCI devices. And also the BIOS!

But the Xen project is moving further to avoid emulation, mainly because it's costly (performances, especially for heavy I/O load, like disks and networks). That's where the PVHVM mode starts: a HVM VM running Linux, detecting Xen underneath, will "activate" the usage of PV interfaces, thus reducing the emulation need.

Using PVHVM could be faster than purely PV, due to modern hardware capabilities (e.g hardware assisted pagetable virtualization)

Impact

So if you are using Xen in HVM or even PVHVM mode for your guests, it's possible to be affected by some QEMU flaws (not all, because only a small part of QEMU is needed for HVM modes).

But keep in mind: PV guests can't be affected.

Is QEMU that bad? Well, you can't blame them: they did an amazing job, and their software is also used in KVM for example. After the VENOM flaws, it's totally normal to have more people digging into it: remember the Heartbleed story with OpenSSL? Same stuff here: don't blame a project your are using, support them!

Mitagation

There is 2 ways to mitigate the problem:

  1. better community collaboration (closer to the upstream)
  2. software "defense in depth" (sandbox)

Working together

So why Xen project doesn't split-up with QEMU? Because that's not the right strategy.

The best answer is more collaboration between QEMU consumers and the upstream. That's exactly why there is more and more discussions and joint meetings between KVM, Xen and QEMU folks, from features to security. Remember the power of Open Source, right?

Xen project is also making progresses to getting closer to the QEMU upstream, thus reducing the time to backport patches.

KVM is also prone to QEMU flaws

Containing

Containing, aka "sandboxing" is a way of "defense in depth".

The idea is to run QEMU as a non-privileged user. This way, a flaw in QEMU won't have an dangerous impact on your system. This work already started, as you can read here.

In XenServer

Because XenServer is a turnkey distro running Xen + XAPI and other patches, they also included QEMU running de-privileged. Despite that's a custom way to do it (at the OS level), it allows XenServer to be already resilient to that kind of flaws.

Blessing in disguise

After all, those flaws are a blessing in disguise. Because they helped to bring together QEMU, Xen and KVM to improve the software itself.

But also for the Xen project directly, because sandboxing is a powerful solution to increase security.

And finally, Xen already offers similar mechanism with Dom0 disaggregation and stub domains: