Updated to v3 on Dec 12th!
Google’s Project Zero announced several information leak vulnerabilities affecting all modern superscalar processors. Details can be found on their blog, and in the Xen Project Advisory 254. To help our users understand the impact and our next steps forward, we put together the following FAQ.
Note that we will update the FAQ as new information surfaces.
Changes since the initial publication:
- v3: Added information related to Comet mitigation for Variant 3 (Meltdown) – for now Xen 4.10 only
- v2: Added information related to Vixen mitigation for Variant 3 (Meltdown) – see Are there any patches for the vulnerability?
- v2: Replaced SPx with Variant x to be in line with the terminology used elsewhere vulnerability?
Is Xen impacted by Meltdown and Spectre?
There are two angles to consider for this question:
- Can an untrusted guest attack the hypervisor using Meltdown or Spectre?
- Can a guest user-space program attack a guest kernel using Meltdown or Spectre?
Systems running Xen, like all operating systems and hypervisors, are potentially affected by Spectre (referred to as Variant 1 and 2 in Advisory 254). For Arm Processors information, you can find which processors are impacted here. Â In general, both the hypervisor and a guest kernel are vulnerable to attack via Variant 1 and 2.
Only Intel processors are impacted by Meltdown (referred to as Variant 3 in Advisory 254). On Intel processors, only 64-bit PV mode guests can attack Xen using Variant 3. Guests running in 32-bit PV mode, HVM mode, and PVH mode (both v1 and v2) cannot attack the hypervisor using Variant 3. However, in 32-bit PV mode, HVM mode, and PVH mode (both v1 and v2), guest userspaces can attack guest kernels using Variant 3; so updating guest kernels is advisable.
Interestingly, guest kernels running in 64-bit PV mode are not vulnerable to attack using Variant 3, because 64-bit PV guests already run in a KPTI-like mode.
However, keep in mind that a successful attack on the hypervisor can still be used to recover information about the same guest from physical memory.
Is there any risk of privilege escalation?
Meltdown and Spectre are, by themselves, only information leaks. There is no suggestion that speculative execution can be used to modify memory or cause a system to do anything it might not have done already.
Where can I find more information?
We will update this blog post and Advisory 254 as new information becomes available. Updates will also be published on xen-announce@.
We will also maintain a technical FAQ on our wiki for answers to more detailed technical questions that emerge on xen-devel@ (and in particular this e-mail thread) and other communication channels.
Are there any patches for the vulnerability?
We have published a mitigation for Meltdown on Intel CPUs: please refer to Advisory 254. The published solutions are labelled Vixen and Comet (also see README.which-shim). Alternative solutions are being worked on.
A Mitigation for Variant 2/CVE-2017-5715 is available on the xen-devel@ mailing list, but has not yet undergone rigorous enough review to be published as an official patch.
As information related to Meltdown and Spectre is now public, development will continue in public on xen-devel@ and patches will be posted and attached to Advisory 254 as they become available in the next few days.
Can Variant 1/Variant 2 be fixed at all? What plans are there to mitigate them?
Variant 2 can be mitigated in two ways, both of which essentially prevent speculative execution of indirect branches. The first is to flush the branch prediction logic on entry into the hypervisor. This requires microcode updates, which Intel and AMD are in the process of preparing, as well as patches to the hypervisor which are also in process and should be available soon.
The second is to do indirect jumps in a way which is not subject to speculative execution. This requires the hypervisor to be recompiled with a compiler that contains special new features. These new compiler features are also in the process of being prepared for both gcc and clang, and should be available soon.
Variant 1 is much more difficult to mitigate. We have some ideas we’re exploring, but they’re still at the design stage at this point.
Does Xen have any equivalent to Linux’s KPTI series?
Linux’s KPTI series is designed to address Variant 3 only. For Xen guests, only 64-bit PV guests are able to execute a Variant 3 attack against the hypervisor. A KPTI-like approach was explored initially, but required significant ABI changes.  Instead we’ve decided to go with an alternate approach, which is less disruptive and less complex to implement. The chosen approach runs PV guests in a PVH container, which ensures that PV guests continue to behave as before, while providing the isolation that protects the hypervisor from Variant 3. This works well for Xen 4.8 to Xen 4.10, which is currently our priority.
For Xen 4.6 and 4.7, we are evaluating several options, but we have not yet finalized the best solution.
Devicemodel stub domains run in PV mode, so is it still more safe to run device models in a stub domain than in domain 0?
The short answer is, yes, it is still safer to run stub domains than otherwise.
If an attacker can gain control of the device model running in a stub domain, it can indeed attempt to use these processor vulnerabilities to read information from Xen.
However, if an attacker can gain control of a device model running in domain 0 without deprivileging, the attacker can gain control of the entire system. Â Even with qemu deprivileging, the qemu process may be able to execute speculative execution attacks against the hypervisor.
So although XSA-254 does affect device model stub domains, they are still safer than not running with a stub domain.
What is the Xen Project’s plan going forward?
The Xen Project is working on finalizing solutions for Variant 3 and Variant 2 and evaluating options for Variant 1. If you would like to stay abreast on our progress, please sign up to xen-announce@. We will update this FAQ as soon as we have more news and updated information. Answers to more detailed technical questions will be maintained in a technical FAQ on our wiki. Thank you for your patience.
How can I ask further questions?
Please respond to this e-mail thread on xen-devel@ or xen-users@.
