[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ
On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@xxxxxxxxx> wrote:
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.
Very helpful, thanks. 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 Linux kernel's IBRS patchset has a doc link which compares retpoline, IBRS Dynamic ("opt-in") and IBRS Always On ("opt-in if more paranoid").
"This repo is an attempt to collect information on the class of information disclosure vulnerabilities caused by CPU speculative execution that were disclosed on January 3rd, 2018. Existing nomenclature is inconsistent and there is no agreed-upon name for the entire class of bugs, but the names Spectre and Meltdown have been used for subclasses of attacks. This is a combination of publicly available information and educated guesses/ speculation based on the nature of the attacks. Pull requests with corrections or discussion are welcome."
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.
Since PVH does not yet support PCI passthrough, are there other recommended SP3 mitigations for 64-bit PV driver domains? Would CPU pinning of an untrusted guest driver domain reduce its ability to attack the host?
Since 32-bit PV guests are not affected by SP3, will they continue to run without a PVH container, so that PCI passthrough continues to function?
Rich 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
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
