Tag Archives: security

Fedora 20 Virtualization Test Day Report

So, it was Fedora Virtualization Test Day last Tuesday and I actually went down and took the occasion for some good testing of Xen on the next Fedora release (Fedora 20, codename Heisenbug). Fedora is going to ship Xen 4.3 (and there are not many other mainstream distribution doing that), so it is very important to try to make sure it will be as good as possible for Fedora users!

A lot of information on how to (well, how you should have… but it’ll be for next time ;-P) participate  to such event are available on our Wiki. What I am up to, here, is reporting how some of the tests I did that day went. Hopefully, this would give an idea of where we stand, regarding the integration of Xen in Fedora, as well as how well Xen itself works with Fedora’s default virtualization toolstack, i.e., libvirt.

Setting up the testing environment

Well, you at least need a Fedora 20 installation, in order to test Xen on Fedora 20. For the details, have a look at the already mentioned wiki page. Here I’m only going to say that I decided to go for a PXE-boot based install, which I did by downloading the following files:

 $ wget http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Fedora/x86_64/os/images/pxeboot/vmlinuz
 $ wget http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Fedora/x86_64/os/images/pxeboot/initrd.img

and by preparing an appropriate entry in my PXE server configuration (usually a file called pxeconfig.cfg):

label fedora-20btc1-amd64-s
    KERNEL fedora/20/x86_64/Beta-TC2/vmlinuz
    APPEND initrd=fedora/20/x86_64/Beta-TC2/initrd.img repo=http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Fedora/x86_64/os/ console=ttyS0,115200n8 text serial

Screenshot from 2013-10-08 15_19_37

Mind the console=ttyS0,115200n8 text serial in case you want to run the install on a serial console, like I’m doing in this case.

On a second test box, I did a proper graphical install (still via PXE). No big difference, really, just follow the guided procedure, then grab a coffe` and wait for this screen (on the right) to happear.

Installing Xen and rebooting into Dom0

After finishing installing the host, we need to install Xen, libvirt and some libvirt related tools. It’s all described in this other Wiki page, so let’s skip it here…. Just follow that instructions and reboot into the following:

Fedora release 20 (Heisenbug)
Kernel 3.11.2-301.fc20.x86_64 on an x86_64 (hvc0)

odyn login: root

# cat /etc/fedora-release 
Fedora release 20 (Heisenbug)
# sudo uname -a
Linux odyn.uk.xensource.com 3.11.3-301.fc20.x86_64 #1 SMP Thu Oct 3 00:57:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
# virt-what 

Well, I guess we can make a note of the first important fact of the Test Day:

  • Fedora 20 works quite nicely and straightforwardly as Xen Dom0!

Creating guests

Ok, let’s move forward to creating some guest. In Fedora, when you want to create and install a guest, especially a Fedora guest, you do it with virt-install. Period. So, let’s do that, a Fedora 20 PV guest, on a Fedora 20 Dom0, with virt-install, installed from the serial console too. It’s actually more easily done than said:

 # lvcreate -nf20_64 -L10G /dev/fedora_odyn
 # virt-install --paravirt --name f20_64 --ram 2048 --vcpus 4 -f /dev/fedora_odyn/f20_64 --network bridge=virbr0 --location http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Fedora/x86_64/os/ --graphics none

 1) [x] Installation source               2) [!] Timezone settings
        (http://dl.fedoraproject.org/pu          (Timezone is
        b/alt/stage/20-Beta-TC1/Fedora/          not set.)
        x86_64/os/)                       4) [!] Set root password
                                                 (Password is not set.)
 3) [!] Install Destination               6) [!] Software selection
        (No disks selected)                      (GNOME Desktop)
 5) [!] Create user
        (No user will be created)
 7) [x] Network settings
        (Wired (eth0) connected)
  Please make your choice from above ['q' to quit | 'c' to continue |
  'r' to refresh]: 
[anaconda] 1:main* 2:shell  3:log  4:storage-log  5:program-log

Let’s now head to my second test box, and do something similar, which lead us where this screenshot shows:

Screenshot from 2013-10-08 16_50_31

I also created another PV guest and an HVM guest there, with similar procedures. From all this, we can reasonably assess the following:

  • Fedora 20 works fine both as a PV and HVM Xen guest.

Playing with the guests with virsh

Now, what about, seeing what we have running:

# virsh list
Id Name State
39     F20-HVM                               running
40    fedora20                               running

Pausing and resuming both the PV and HVM guests:

# virsh suspend F20-HVM
Domain F20-HVM suspended
# virsh suspend fedora20
Domain fedora20 suspended
# virsh list
Id Name State
39      F20-HVM                               paused
40     fedora20                               paused

# virsh resume F20-HVM
Domain F20-HVM resumed
# virsh resume fedora20
Domain fedora20 resumed
# virsh list
Id Name State
39     F20-HVM                               running
40    fedora20                               running

And, finally, saving-&-restoring one of them

# virsh save fedora20 /tmp/savefile
Domain fedora20 saved to /tmp/savefile
# virsh list
Id Name State
39      F20-HVM                              running

# virsh restore /tmp/savefile
Domain restored from /tmp/savefile
# virsh list
Id Name State
39      F20-HVM                              running
41     fedora20                              running

I also tried importing and cloning a VM, as described here and here, and it all worked.

Any issues, then? There indeed was one. Basically, it looks like reaching the guest’s PV console via virsh does not work, while it is fine with xl console:

# virsh console fedora20
Connected to domain fedora20
Escape character is ^]
error: internal error: cannot find character device (null)

# xl console fedora20
Fedora release 20 (Heisenbug)
Kernel 3.11.2-301.fc20.x86_64 on an x86_64 (hvc0)

fedora20 login: root
[root@fedora20 ~]#

And I will of course report that to the appropriate mailing list/bugzilla.

What’s there, what’s missing

The previous section reveals that not only Xen is straightforward to install and works quite well on Fedora 20 as a Dom0, and that Fedora 20 works quite well as a Xen PV or HVM guest. It also shows how the basic VM lifecycle of a Xen guest, in Fedora 20, can be handled nicely enough with libvirt and the related tools (virt-install, virt-manager, virt-viewer, etc.). That of course does not exclude the possibility of using Xen’s default command line toolstack (xl).

The only two relevant missing features, at the time of writing, in the libvirt libxl driver are:

  • PCI Passthrough
  • live migration

Yes, big ones, I know. However, consider the following:

  1. that does not mean that PCI Passthrough and migration does not work on Xen on Fedora at all. They do work via the xl toolstack, they are just not available via libvirt;
  2. this is going to be solved soon, as the libvirt libxl driver maintainer Jim Fehling reported recently on xen-devel. In fact, this is the patch series for PCI Passthrough, and this is the patch series implementing live migration, and there are pretty good chances that both these patches make it in libvirt before Xen 4.4 release time (so, not in time for Fedora 20, but still not bad at all).

So, stay tuned since, as Jim says, “Slowly, with each libvirt release, the libxl driver is improving”.


Fedora really does a great job with these Test Days. All of it: the planning, the managing, the reporting… An example that many other project should look at and try to follow (and actually, Xen Project is trying, as we also started having Xen Test Days).

Participating to the latest Fedora Virtualization Test Day has been really nice, although we need to do a better job in convincing more Xen folks to be there and do some Xen specific testing. Anyway, I am really glad to have had the chance to verify how well Xen 4.3 will work on Fedora 20.

It is actually quite important that we get a good Xen on Fedora test coverage, at least as far as running the next release of Fedora as a Xen DomU is concerned. In fact, being a functional Xen guest is one of the release blockers for a Fedora release, as in, if release X does not work as a Xen guest, it can’t be released!

Since testing Xen on Fedora is, for the most part, testing Xen integration with libvirt, what about producing some libvirt test-cases for OSSTest? That would be very cool, and we are already working on it. Another interesting thing would be to also have OSSTest could try to build and run Xen on various distro (as host), instead than using only Debian, as it is doing right now. This is a bit more tricky than the above, but we are thinking at how to do that too (standalone mode could, perhaps, help).

Indirect descriptors for Xen PV disks

Some time ago Konrad Rzeszutek Wilk (the Xen Linux maintainer) came up with a list of possible improvements to the Xen PV block protocol, which is used by Xen guests to reduce the overhead of emulated disks.

This document is quite long, and the list of possible improvements is also not small, so we decided to go implementing them step by step. One of the first items that seemed like a good candidate for performance improvement was what is called “indirect descriptors”. This idea is borrowed from the VirtIO protocol, and to put it clear consists on fitting more data in a request. I am going to expand how is this done later in the blog post, but first I would like to speak a little bit about the Xen PV disk protocol in order to understand it better.

Xen PV disk protocol

The Xen PV disk protocol is very simple, it only requires a shared memory page between the guest and the driver domain in order to queue requests and read responses. This shared memory page has a size of 4KB, and is mapped by both the guest and the driver domain. The structure used by the fronted and the backend to exchange data is also very simple, and is usually known as a ring, which is a circular queue and some counters pointing to the last produced requests and responses.

Continue reading

Reporting A Bug Against the Xen Hypervisor

With the release process for Xen 4.3 in full swing (we intend to release the third release candidate this week) and with the Xen Test Days initiative (the next one is this Wednesday 5 June, join us on IRC freenode #xentest) I thought it would be useful to offer up some information and guidance on how the Xen project deals with bug reports and how to report bugs against the Xen Hypervisor Project.

Reporting a Bug

Confirm That Your Issue Is a Bug

Experience has shown that oftentimes what appears to be a bug is often just a misconfiguration or misunderstanding of how things are supposed to work. This can be down to a lack of documentation (a perennial problem for Open Source projects and something which we are working to address with our regular Xen Document Days) or the inherent complexity of something of the things which one can achieve (or try to achieve!) using Xen.

With that in mind it is often useful to try seeking help via other means before resorting to submitting a bug report. Useful resources for asking questions are:

  • In a Xen system logs the logs can usually be found in /var/log/xen and will sometimes provide useful insight into an issue.
  • Search engines. As well as simply searching for key terms relating to your issue you can also search the User and Developer list archives.
  • Continue reading

Xen.org Security Policy Update: Get Involved

Xen.org recently released a number of (related) security updates, XSA-7 through to -9. This was done by the Xen.org Security Team who are charged with following the Xen.org Security Problem Response Process.

As part of the process of releasing XSA-7..9 several short-comings (a few of which Ian Jackson has discussed already in Security vulnerabilities – the coordinated disclosure sausage mill) were found in the process.

In order to address these short-comings we have started a discussion on the xen-devel mailing list which describes the issues which we faced and proposes some potential options for updates. However this process is supposed to serve you, the Xen user community, and therefore your feedback and input is critical to ensuring that the policy meets the needs of the community.

So whether you are a small or large consumer of Xen you should feel free to have your say and to help formulate an updated policy which best serves the needs of the community. To take part in the discussion please send mail to xen-devel@lists.xen.org.

The Intel SYSRET privilege escalation

The Xen Security team recently disclosed a vulnerability, Xen Security Advisory 7 (CVE-2012-0217), which would allow guest administrators to escalate to hypervisor-level privileges. The impact is much wider than Xen; many other operating systems seem to have the same vulnerability, including NetBSD, FreeBSD, some versions of Microsoft Windows (including Windows 7).

So what was the vulnerability? It has to do with a subtle difference in the way in which Intel processors implement error handling in their version of AMD’s SYSRET instruction. The SYSRET instruction is part of the x86-64 standard defined by AMD. If an operating system is written according to AMD’s spec, but run on Intel hardware, the difference in implementation can be exploited by an attacker to write to arbitrary addresses in the operating system’s memory. This blog will explore the technical details of the vulnerability.
Continue reading

NUMA and Xen: Part II, Scheduling and Placement

Where were we?

So, here it is what we said up to now. Basically:

  1. NUMA is becoming increasingly common;
  2. properly dealing with NUMA is important for performance;
  3. one can tweak Xen for NUMA, but it would be nice for that to happen automagically!

So, let’s tackle some automatic NUMA handling mechanisms this time!

NUMA Scheduling, whatsit

Suppose we have a VM with all its memory allocated on NODE#0 and NODE#2 of our NUMA host. As already said, the best thing to do would be to pin the VM’s vCPUs on the pCPUs related to the two nodes. However, pinning is quite unflexible: what if those pCPUs get very busy while there are completely idle pCPUs on other nodes? It will depend on the workload, but it is not hard to imagine that having some chance to run –even if on a remote node– would be better than not running at all! It is therefore preferable to give the scheduler some hints about where a VM’s vCPUs should be executed. It then can try at its best to honor these requests of ours, but not at the cost of subverting its own algorithm. From now on, we’ll call this hinting mechanism node affinity (don’t confuse it with CPU affinity, which is about to static CPU pinning).

Continue reading