Re: [Xen-users] [Xen-devel] Xen Project Spectre/Meltdown FAQ

[Hans van Kranenburg <hans@xxxxxxxxxxx>]

On 01/05/2018 12:35 PM, Lars Kurth 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. 
> Regards Lars

Thanks for the writeup.

The main reason for the reader to get confused is the amount of
different combinations of situations that are possible, which all again
have their own set of vulnerabilities and also their own (maybe even
different) set of possibilities to be used as environment for executing
an attack.

So let's help them by being more explicit.

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

"On Intel processors an attack at Xen using SP3 can only be done by
64-bit PV mode guests."

Even if it looks super-redundant, I think keeping explicit information
in every sentence is preferable, so they cannot be misinterpreted or
accidentally be taken out of context.

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

Like Juergen already mentioned, additionally: "However, keep in mind
that a succesful 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 [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.

This one...

> For Xen guests, only 64-bit PV guests are affected by SP3.

...should be more explicit. The words "affected" and "impacted" do not
tell the reader if it's about being an attacker, or about being the
victim and what is attacked or attacking.

"For Xen guests, only 64-bit PV guests are able to execute a SP3 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 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
> 


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-users