Monthly Archives: October 2014

Xen Project Developer Summit Videos and Slides

It has been a while since we held the Xen Project Developer Summit. All slides have been posted on our slideshare channel (prefixed with XPDS14) and are also available on youtube. Slides and videos are also available on the presentation & video page of our website (again, just search for XPDS14). A few videos are still missing, due to editing issues and will follow shortly.

A few of my personal highlights

Xen 4.4 Retrospective and 4.5 Roadmap

Talk by George Dunlap and Konrad R Wilk covering the how we managed the Xen Project 4.4 release and the 4.5 Roadmap. You may also want to check out information related to our first Xen 4.5 Release candidate.

Xen as High-Performance NFV Platform

Towards Massive Server Consolidation

Although not entirely related, the following talk shows some experiments and improvements to Xen which NEC has performed which allow up to 10K guests to run on a Xen host.

Embedded topics

The following talks were interesting and relevant for new use cases, such as automotive, Xen Project in avionics and similar,

Unikernels and Library OS’es

If you are interested in Unikernels, check out the following talks:

Of course, there are many more. Enjoy!

October 29: Xen Project 4.5 RC1 Test Day


The Xen Project team is pleased to announce the first Test Day for 4.5 Release Candidate 1 will be held on October 29, 2014.  The 4.5 release is just a few weeks away, so this is an important event in our development calendar.

Test Days insure that the upcoming release is ready for production.  It also allows power users to test out the upcoming release in their own environment.

Subsequent Test Days are expected to be scheduled roughly ever other week until it is determined that the software is ready for release.

General Information about Test Days can be found here:

and specific instructions for this Test Day are located here:


If you have a new feature which is cooked and ready for testing in RC1, we need to know about it and how to test it. Either edit the instructions page or send me a few lines describing the feature and how it should be tested.

Currently, this Test Day is focused on general tests (e.g., “Does the software compile, install, and do the things it normally does, regardless of hardware platform?”).  If you have specific new functionality which needs testing in RC1, we need to know about it and how to test it.


Please join us on Wednesday, October 29, and help make sure the next release of Xen Project software is the best one yet!  To make room for the Test Day, we’ve moved Document Day back to November 5, so join us then as we improve documentation with a special theme of integration this month.

Xen Project Security Policy Improvements: Get Involved

The recent XSA-108 vulnerability resulted in a lot of media coverage, which ended up stress-testing some of our policy and security related processes. During the embargo period of XSA-108, the Xen Project Security Team was faced with some difficult questions of policy interpretation, as well as practical issues related to pre-disclosure list membership applications.

To ensure more clarity moving forward, the Xen Project Security Team started a community consultation to improve and better define the project’s Security Vulnerability Response Process. In particular we are seeking to clarify the following elements of the policy, which surfaced during the embargo period of XSA-108:

  • Sharing of information amongst pre-disclosure list members during an embargo period
  • Deployment of patches on public systems of fixed versions of the Xen Project Hypervisor during the embargo period
  • Service announcements to non-list-member users during an embargo period
  • Clarifying criteria related to pre-disclosure list membership and making it easier to verify them
  • Processing applications of pre-disclosure list membership during an embargo period

For more background and information read the e-mail thread on xen-devel@ called Security policy ambiguities – XSA-108 process post-mortem (also see here to see the entire conversation thread in one place).

If you use Xen Project Software in any way, we encourage you to voice your thoughts to help formulate and update our security policy to ensure it meets the needs of our entire community. To take part in the discussion please send mail to If you are a member of the list just reply to the relevant thread. If you are not a member of the mailing list and plan to respond to an e-mail that has already been sent you have two easy options:

  • You can reply to the message via our issue tracker using the Reply to this message link at the top of the message; or
  • Retrieve the mbox from the issue issue tracker, load the thread into your mail client and just reply.

Even if you chose not to subscribe to xen-devel@ – which you don’t have to participate – you may want to occasionally check the discussion thread activity on this thread, to ensure you are not missing any activity.

Going forward, we will collate community input and propose a revised version of the policy, which will be formally approved in line with Xen Project Governance. We have not set a specific deadline for the discussion, but aim to issue a revised policy within 4 weeks.

The Windows PV Drivers Sub-Project

by Paul Durrant

Back in 2013 Citrix made XenServer fully open source. As part of that work the previously closed Windows drivers for paravirtual devices were opened up and made available to the community on GitHub. These drivers were still very much tied to XenServer though because of assumptions that were made about the platform and reliance on certain patches carried in the XenServer patch queues.

Shortly after setting up the driver repositories on GitHub I started removing these assumptions and dependencies on the XenServer platform and produced a set of drivers that could be used on most Xen installations. This put the code in a good state to approach the project community and Xen Project Advisory Board with a proposal for an incubation sub-project. I’m happy to say that this was and we are well under way in getting things set up. There is a new with information on the driver source repositories (which are now hosted on xenbits under a new pvdrivers/win sub-directory), instructions on how to build and install the drivers, and guidelines on how to contribute to the project.


The PV drivers are split into five packages:


This is the key package that supports all other PV drivers. It provides the XENBUS driver which binds to either the XenServer variant of the (see in the hypervisor source repository) or the ubiquitous Xen Platform PCI Device, both of which are provided to HVM guests by QEMU.
This driver establishes communication with the Xen hypervisor and enumerates the paravirtual classes specified by the toolstack in xenstore. It also provides APIs to core Xen functionality such as event channels and the grant table.


This package contains the network class driver XENVIF. This driver makes use of the APIs provided by XENBUS to implement the PV network protocol. It enumerates PV network devices (specified in the guest area in xenstore under device/vif) and provides a simple API to use the protocol.


This package contains the NDIS 6 network device driver XENNET. This driver binds to the devices enumerated by XENVIF and provides a relatively thin glue layer between the Microsoft-defined NDIS miniport interface and the PV network API exported by XENVIF.


This package contains the storage class driver XENVBD and associated crash-kernel driver XENCRSH. XENVBD makes use of the APIs provided by XENBUS and the Windows STORPORT miniport interface to provide limited SCSI HBA functionality to the OS. It is limited in the fact that it only supports the operations necessary for the Windows generic DISK driver to function on the devices exposed by the HBA.


This package contains the XENIFACE driver which creates WMI objects providing access to xenstore (see ) and system time, and a minimal user-space guest agent which uses those objects to provide facilities to cleanly shut down or reboot a guest and also re-synchronize guest time after a VM migrate/restore.

XSA-108: Not the vulnerability you’re looking for

There has an unusual amount of media attention to XSA-108 during the embargo period (which ended Wednesday) — far more than any of the previous security issues the Xen Project has reported. It began when a blogger complained that Amazon was telling customers it would be rebooting VMs in certain regions before a specific date. Other media outlets picked it up and noticed that the date happened to coincide with the release of XSA-108, and conjectured that the reboots had something to do with that. Soon others were conjecturing that, because of the major impact to customers of rebooting, that it must be something very big and important, similar to the recent Heartbleed and Shell Shock vulnerabilities. Amazon confirmed that the reboots had to do with XSA-108, but could say nothing else because of the security embargo.

Unfortunately, because of the nature of embargoes, nobody with any actual knowledge of the vulnerability was allowed to say anything about it, and so the media was entirely free to speculate without any additional information to ground the discussion in reality.

Now that the embargo has lifted, we can talk in detail about the vulnerability; and I’m afraid that people looking for another Shell Shock or Heartbleed are going to be disappointed. No catchy name for this one.

Continue reading

XSA-108: Additional Information from the Xen Project

The Xen Project Security Team today disclosed details of the Xen Security Advisory 108 / CVE-2014-7188 (Improper MSR range used for x2APIC emulation). The Xen Project does not normally comment on specific vulnerabilities other than issuing security advisories. However, given wide interest in this case, we believe it is helpful to provide more context. The recent Shellshock bug in Bash and the Heartbleed bug in OpenSSL last spring have put a spotlight on software security issues. Due to the proximity of the Shellshock bug and announcements of maintenance reboots from some cloud service providers, there was substantial speculation about XSA-108 among bloggers, tweeters, and reporters. For the Xen Project Security Team, XSA-108 started as a security issue like any other, but this speculation quickly turned an ordinary bug fix into an extraordinary event.

A Technical Overview of XSA-108

XSA-108 was caused by a bug in the emulation code used when running HVM guests on x86 processors. The bug allows an attacker with elevated guest OS privileges to crash the host or to read up to 3 KiB of random memory that might not be assigned to the guest. The memory could contain confidential information if it is assigned to a different guest or the hypervisor. The vulnerability does not apply to PV guests.

Why Security Matters

Managing vulnerabilities and bug fixes is par for the course in any software code base. All software has bugs, and some bugs have security implications. Hypervisors play a critical role in the security of many systems; therefore, the Xen Project community has collaboratively developed a mature and robust process for handling security problems. The Xen Project Security Team works with organizations that meet criteria set by the community to protect users, while limiting the risk that a security vulnerability can be used by an attacker.

A Unique Open Source Security Process

The Xen Project developed its Security Policy to:

  • Encourage people who find security issues to report them in private.
  • Enable software vendors who distribute Xen Project software, public cloud and hosting providers and large scale users of Xen Project Software to address an issue in private such that risk of exposure to their users is minimized.

The current version of our security policy was established through an open community collaboration, which focused on issues of fairness between large and small vendors while controlling the distribution of sensitive information.

We believe that no other open source community has established a security process and policy as open and transparent as ours. As a result, the policy meets the demands of multiple stakeholders all with very different needs.

We believe that the process has been working well, as it did for XSA-108. Several cloud providers updated their servers, something that they decided was necessary in this case to best ensure their users were not put at risk. Most likely smaller vendors have done the same. Product vendors and Linux distributions will make updates available to their users following the embargo date.

But as we have learned from open source software development, there is always room for improvement through proposing changes and discussing their merits.

Lessons Learned

The speculation around XSA-108 highlighted a number of areas where we can improve. For example, we may need to adjust how we handle a sudden influx of applications to join the Xen Project Security pre-disclosure list. Also, the security policy could be clarified to ensure all members on the pre-disclosure list better understand what’s expected of them during the embargo period.

As pointed out earlier, our security process has worked extremely well for the last three years and has protected users of Xen Project software. This also holds true in this case. Software and service providers have been able to prepare updates in advance of disclosure and, consequently, users are more secure.

What’s Next?

We also need to recognize that public interest in software security and vulnerabilities will likely continue, if not increase. Next week, we will start an open discussion on our mailing lists, to make any necessary adjustments to our security process in light of pressure exerted on vendors as well as community members during the embargo period for XSA-108.

Additional Information: