[Xen-devel] Xen Project Spectre/Meltdown FAQ

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

Hi all, this is a repost of 
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for 
xen-users/xen-devel. If you have questions, please reply to this thread and we 
will try and improve the FAQ based on questions.
Regards
Lars


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 [1]. 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.

= 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 SP1 and SP2 in Advisory 254 
[1]). For Arm Processors information, you can find which processors are 
impacted here [2].  In general, both the hypervisor and a guest kernel are 
vulnerable to attack via SP1 and SP2.

Only Intel processors are impacted by Meltdown (referred to as SP3 in Advisory 
254 [1]). On Intel processors, only 64-bit PV mode guests can attack Xen. 
Guests running in 32-bit PV mode, HVM mode, and PVH mode cannot attack the 
hypervisor using SP3. However, in 32-bit PV mode, HVM mode, and PVH mode, guest 
userspaces can attack guest kernels using SP3; so updating guest kernels is 
advisable.

Interestingly, guest kernels running in 64-bit PV mode are not vulnerable to 
attack using SP3, because 64-bit PV guests already run in a KPTI-like mode.

= 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 [1] as new information becomes 
available. Updates will also be published on xen-announce@.

We will also maintain a technical FAQ on our wiki [3] for answers to more 
detailed technical questions that emerge on xen-devel@ and other communication 
channels.

= Are there any patches for the vulnerability? =

We have prototype patches for a mitigation for Meltdown on Intel CPUs and a 
Mitigation for SP2/CVE-2017-5715, which are functional but have not undergone 
rigorous review and have not been backported to all supported Xen Project 
releases.

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 [1] as they become available in the next few days.

= Can SP1/SP2 be fixed at all? What plans are there to mitigate them? =

SP2 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.

SP1 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 SP3 only.  For Xen guests, only 
64-bit PV guests are affected by SP3. 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 SP3. 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 SP3 and SP2 and 
evaluating options for SP1. 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 [3]. Thank you for your 
patience.

= How can I ask further questions? =
Please respond to this e-mail thread on xen-devel@ or xen-users@

References
[1] http://xenbits.xen.org/xsa/advisory-254.html
[2] https://developer.arm.com/support/security-update
[3] 
https://wiki.xenproject.org/wiki/Xen_Project_Meltdown_and_Spectre_Technical_FAQ
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel