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.

What is the vulnerability?

XSA-108 has to do with the emulation of a piece of hardware called an x2APIC. x2APIC is an interrupt controller: it allows the operating system to control when and how and where urgent messages from outside the chip, and from other cores within the same chip, are delivered.
Interrupt controllers occupy a rather awkward position in the architecture. They are fairly complicated to implement in hardware. Earlier generations of Intel hardware don’t have any APIC emulation at all; hardware since since the Ivy Bridge architecture (which came out in mid-2012) implement only part of the functionality, leaving the rest to be emulated elsewhere. But they are far too performance critical for Xen to pass emulation off to QEMU, as it does with virtual disks or virtual networks. This means that they must be emulated within Xen.
The actual vulnerability, like most vulnerabilities, is pretty simple. Xen implements 256 x2APIC registers. These registers are stored in a buffer big enough to hold exactly 256 registers. However, the limit check for reading these registers was erroneously set to 1024.
What this means is that, without the fix, if you read x2APIC registers 0-255, you’ll get the correct emulated value from the register buffer; but if you read x2APIC registers 256-1023, Xen will read memory from directly after the register buffer. If that memory is not mapped, Xen will crash; if it is mapped, it will copy it to the guest.
So what this bug gives you is the ability to read (and only read) the 12k (or 3k dependind on how you count [1]) of memory directly adjacent to where Xen is storing the first 256 registers (and no other area of memory).
The fix simply corrects the limit check to 256.
The emulated x2APIC functionality was introduced in Xen 4.1, so previous versions of Xen are not affected. Neither are PV guests, since Xen does not provide them with any emulated hardware.
Unfortunately, the presence of VT support emulating the x2APIC, available on newer processors, doesn’t mitigate the issue: it only implements the 64 registers actually used by real hardware at the moment, leaving Xen to emulate the rest of the registers. If you access registers above 64, it will trap to Xen, and Xen will emulate access to them, allowing you to trigger the bug.

The impact

If this seems like a relatively minor issue, that’s because it is. The most likely scenario is that that 12k of memory contains other Xen data structures which contain no important information. There is, however, a chance that this memory might contain memory from another VM; and a chance that this memory might contain sensitive information, like passwords, encryption keys, or other private data.
Nonetheless, this is a security issue, and the Xen Project takes all potential security issues very seriously, no matter how minor. We have a mature process in place to notify cloud providers, distributions, and software providers so that they can have a fix in place before publicly disclosing any vulnerability.
Applying security patches proactively, even though there’s very low risk that anyone might have their secret data leaked because of it, is a conscientious and diligient thing to do. We’re glad to see that so many cloud providers using Xen are demonstrating how seriously they take protecting customer data.
But it is by no means a disaster. Those looking for a juicy vulnerability like Heartbleed and Shell Shock will be disappointed.
[1] Saying either 3k or 12k is simplifiying the truth in different ways. The MSR data is laid out as a 16-byte structure, of which only the first four bytes (one 32-bit word) can be read by this vulnerability. So the actual amount of data which is exposed is 3k, but it’s spread out in 4-byte chunks across 12k of memory.