Xen project Mailing List

On 5 Jan 2018, at 15:55, Hans van Kranenburg <hans@xxxxxxxxxxx> wrote:

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

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