Author Archives: Ian Jackson

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

libxl event API improvements

Over the past few months we have been working on improving the API for the libxl library. libxl is to become the base layer for all Xen toolstacks. We intend the version of libxl in Xen 4.2 to have a stable interface, with which we will maintain backward compatibility for some time to come.

The Xen 4.1 libxl API had some awkward features. Particularly, dealing with long-running operations, and getting information about events such as domain death, was difficult to do correctly in daemons such as libvirt’s virtd and XCP/XenServer. For example, the wait for domain death facility did not tell you which domain had died! And many of the functions would block a whole event-loop-based process while a long-running operation completed. The new arrangements are intended to support everything from the simple xl command line utility, to event-callback-based daemons such as virtd, and also to be convenient for use in multithreaded programs.

This has required a lot of behind-the-scenes infrastructure, which insulates libxl code implementing specific VM operations from the need to know about the calling toolstack’s concurrency model. As I write this, the changes are already in the xen-unstable.hg tree undergoing testing, and we are putting the finishing touches to the APIs.

Continue reading

Budapest and the Ubuntu Developer Summit

Last week I was at the Ubuntu Developer Summit in Budapest.

The best news is: the next release of Ubuntu, oneiric ocelot, will have dom0-capable kernels in main and Xen (4.1, very likely) hypervisor/tools in universe. The plan is to have the hypervisor and tools in main in the next LTS. This is a great step forward.

I’d just like to say a big thank you to all those of you who’ve worked so hard (and had your patience so sorely tested!) getting Xen dom0 support into Linux upstream. Now we are really starting to reap the rewards.

“Cloud” topics were quite prominent in the agenda generally. Both
OpenStack and Eucalyptus were well represented, and there’s exciting new stuff in the field of “cloud orchestration” (eg Ensemble). We need to do some background work to make a readily buildable set of Xapi packages for OpenStack at least, as OpenStack’s Xen integration is via Xapi.

Of course as a longstanding Ubuntu and Debian developer, I attended various other sessions where I was able to help out, and I met a lot of old and new friends. Also outside of the formal programme, there was a lot of interest in Xen.

Perhaps the highlight of the conference’s social programme for me was the Invisible Exhibition fringe event: at this exhibition, which is entirely in the dark, we wandered through a series of scenes which we explored by touch. One aim of the exhibition is to help understand the experience of blind and visually impaired people.

On the personal side: I had nearly two weekends in Budapest, which is an excellent and exciting city; I recommend it. I was particularly impressed by the Children’s Railway and Memento Park.