Monthly Archives: June 2012 Security Policy Update: Get Involved recently released a number of (related) security updates, XSA-7 through to -9. This was done by the Security Team who are charged with following the 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 4.2 Release Plan Update

It’s been a while since the last 4.2 release update and a lot has
changed since then, so I suppose it is time for another update.

Way back at the start of April I posted the previous
which suggested we’d be doing the first release candidates
in mid/late April. Well, as might be expected, that turned out to be
rather optimistic!

Rather than get caught out again I’ve gone for a much more standard OSS
project release time line:

  • 19 March — TODO list locked down
  • 2 April — Feature Freeze
  • When It’s Ready — First release candidate
  • Weekly — RCN+1 until release

The good news is that since the previous update lots of progress has
been made and the list of blockers to release has been getting
smaller. There remains three largish items and a handful of smaller
ones. Almost all of which have seen multiple rounds of review and are
nearing fruition. (NB: items marked [BUG] or [CHECK] are not
considered blockers for RC0)

The list of outstanding issues is posted to xen-devel on a weekly basis, usually on a
Monday. The most recent posting is here.

Xen Document Day: June 28th

We have another Xen document day come up next Monday. Xen Document Days are for people who care about Xen Documentation and want to improve it. Everybody who can and wants contribute is welcome to join!

For a list of items that need work, check out the community maintained TODO and wishlist. Of course, you can work on anything you like: the list just provides suggestions.

See you on IRC : #xendocs @ freenode !

Security vulnerabilities – the coordinated disclosure sausage mill

Laws, like sausages, cease to inspire respect in proportion as we know how they are made. – John Godfrey Saxe, 1869.

Most open source projects, included, do what is called “coordinated disclosure” of security problems. The idea is that we keep security bugs secret until people have had a chance to patch.

Mostly this process looks serene on the outside, but from the inside it can be very messy indeed. Particularly if, as happened recently with XSA-7 / CVE-2012-0217, large and powerful corporations apply pressure to keep the bug and the fix under wraps for months while their sclerotic update processes grind on.

Many of you will already know about this vulnerability, a bug in Intel’s implementation of the sysret instruction in AMD’s amd64 (aka x86_64) processor architecture. George Dunlap has already explained the technical details. This serious problem was discovered in the context of Xen and FreeBSD on the 9th of April. The fix was originally scheduled to go out on the 1st of May but in the end was not made available to all of you, the users, until the 12th of June.

There were some other problems too: we in the security team made some key mistakes. We didn’t involve other organisations early enough, and the patches weren’t written carefully or reviewed closely enough.

So to try to make sure that things go better next time, the team have posted a formal request for discussion about how to improve the policy. This also contains, as an exercise in Free Software / Open Source transparency, a summary of what went on behind closed doors during the embargo period.

If you’ve ever wanted to see how the “coordinated disclosure” sausage is made, here’s a glimpse into that world. Warning: it may put you off. Hopefully it will put you off using the loaded term “responsible disclosure” for something which involves keeping the majority of deployed installations exposed for months to a bug which was first discovered in 2006.

Have your say!

So, following the request for discussion there is now a thread on the xen-devel mailing list to discuss and agree on improvements.

Continue reading

XenSummit : Quick Update

I wanted to thank everybody who submitted a proposal to speak for XenSummit. This year we had the most submissions we ever had. The XenSummit Program Management Committee, which is made up of

  • David Nalley (
  • Donald D Dugger (Intel)
  • Ian Campbell (Citrix)
  • Konrad Rzeszutek Wilk (Oracle) and
  • Lars Kurth (

will have its first meeting later this week. We are hoping that we will be able to announce the XenSummit program in the first week of July. This may be a tall order though, as we will have togo through a lot of very good proposals.

In any case, XenSummit registration is open already and a XenSummit ticket costs USD 99. Information about location, co-located events, hotel bookings, invitation letters and tours of San Diego (for which we have a discount) are on the XenSummit page. I did want remind you that rooms on our block must be booked before 17:00 PST, July 27, 2012. Also note that a quarter of the allocated rooms have already been reserved.

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