Xen Project Spectre/Meltdown FAQ

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Xen Project Spectre/Meltdown FAQ

Lars Kurth-4
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-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users
Reply | Threaded
Open this post in threaded view
|

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

Juergen Gross-3
On 05/01/18 12:35, 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
>
>
> 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.

And this is wrong. Guest kernels running in 64-bit PV mode can't be
attacked directly from their users, but indirectly via a user program
reading the host's memory, of which the guest's kernel memory is a
part of.


Juergen

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Xen Project Spectre/Meltdown FAQ

George Dunlap-5
In reply to this post by Lars Kurth-4
On 01/05/2018 11:35 AM, 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.

I also started a "Practical response" FAQ here:

https://wiki.xenproject.org/wiki/Respond_to_Meltdown_and_Spectre

Please give feedback and add practical information as needed.

 -George

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users
Reply | Threaded
Open this post in threaded view
|

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

Julien Grall-2
In reply to this post by Lars Kurth-4
(apologies for the formatting)

Hi Lars,

Thank you for putting together an FAQ.

Few comments below around Arm.


On 5 Jan 2018 13:37, "Lars Kurth" <[hidden email]> 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


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.

The website list processors designed by Arm (i.e Cortex family). It does not include processors made by Arm licensees. I will leave the various licensees speak for themselves here.

Regarding Arm-designed processors, most of them are not vulnerable to any variant. Those affected will mostly be vulnerable to attack via SP1 and SP2.

But this does not rule out attack via SP3 on Arm. From the website, one Cortex processor is affected.

While this will not affect Xen (the hypervisor is using a different set  of page-tables). Guest kernel will be vulnerable to it.


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
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-devel


_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users
Reply | Threaded
Open this post in threaded view
|

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

Lars Kurth-4
Julien,

On 5 Jan 2018, at 14:40, Julien Grall <[hidden email]> wrote:

(apologies for the formatting)

Hi Lars,

Thank you for putting together an FAQ.

Few comments below around Arm.

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.

The website list processors designed by Arm (i.e Cortex family). It does not include processors made by Arm licensees. I will leave the various licensees speak for themselves here.

Regarding Arm-designed processors, most of them are not vulnerable to any variant. Those affected will mostly be vulnerable to attack via SP1 and SP2.

But this does not rule out attack via SP3 on Arm. From the website, one Cortex processor is affected.

While this will not affect Xen (the hypervisor is using a different set  of page-tables). Guest kernel will be vulnerable to it.

I would be quite happy to have a specific question covering ARM/ARM eco-system where you can explain all this. Feel free to formulate a question + answer and I will add it
Lars

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users
Reply | Threaded
Open this post in threaded view
|

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

Hans van Kranenburg-2
In reply to this post by Lars Kurth-4
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 [hidden email]
> https://lists.xenproject.org/mailman/listinfo/xen-devel
>


_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users
Reply | Threaded
Open this post in threaded view
|

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

Lars Kurth-4

On 5 Jan 2018, at 15:55, Hans van Kranenburg <[hidden email]> 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.

That sounds reasonable

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.

Alright: I think I prefer "On Intel processors, only 64-bit PV mode guests can attack Xen using SP3."


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

Good suggestion.


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

Sounds fine

I will update the blog post sometimes tomorrow or Monday. There were a few further comments, which may be worth rolling into a change

Lars


_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users
Reply | Threaded
Open this post in threaded view
|

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

Lars Kurth-4
In reply to this post by Hans van Kranenburg-2
Hans,
I updated the FAQ on the blog. Thank you for your input. 
Lars

On 5 Jan 2018, at 15:55, Hans van Kranenburg <[hidden email]> 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 [hidden email] 
https://lists.xenproject.org/mailman/listinfo/xen-devel


_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users