Xen Project Spectre/Meltdown FAQ

Xen Project Spectre/Meltdown FAQ

[Lars Kurth]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Spectre/Meltdown FAQ

[Juergen Gross]

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-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Spectre/Meltdown FAQ

[George Dunlap]

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-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen Project Spectre/Meltdown FAQ

[Julien Grall]

[-- Attachment #1.1: Type: text/plain, Size: 7087 bytes --]

(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" <lars.kurth.xen@gmail.com> 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
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 9011 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 1330 bytes --]

Julien,

> On 5 Jan 2018, at 14:40, Julien Grall <julien.grall@linaro.org> 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

[-- Attachment #1.2: Type: text/html, Size: 2928 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Hans van Kranenburg]

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@lists.xenproject.org 
> https://lists.xenproject.org/mailman/listinfo/xen-devel
> 


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

Re: Xen Project Spectre/Meltdown FAQ

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 2692 bytes --]


> On 5 Jan 2018, at 15:55, Hans van Kranenburg <hans@knorrie.org> 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/ <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


[-- Attachment #1.2: Type: text/html, Size: 22681 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Rich Persaud]

[-- Attachment #1.1: Type: text/plain, Size: 7887 bytes --]

> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com> 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").  

https://lkml.org/lkml/2018/1/4/615

https://docs.google.com/document/d/e/2PACX-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkfAY-7lGYGOTN8mc9ul-J6pWadcAaBJZcVA7W_3jlLKRtKRbd/pub

Would be nice to have that comparison for other CPU vendors.  Some information is aggregated at https://github.com/marcan/speculation-bugs:

"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@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 13339 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Andrew Cooper]

[-- Attachment #1.1: Type: text/plain, Size: 3548 bytes --]

On 05/01/18 18:16, Rich Persaud wrote:
>> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
>> <mailto:lars.kurth.xen@gmail.com>> wrote:
>> 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").  
>
> https://lkml.org/lkml/2018/1/4/615
>
> https://docs.google.com/document/d/e/2PACX-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkfAY-7lGYGOTN8mc9ul-J6pWadcAaBJZcVA7W_3jlLKRtKRbd/pub
>
> Would be nice to have that comparison for other CPU vendors.  Some
> information is aggregated at https://github.com/marcan/speculation-bugs:
>
> "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."

Prefer the google names.  Spectre in particular is a mix of two quite
different attack techniques.

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

Lock them down?  Device driver domains, even if not fully trusted, are
going to be part of the system and therefore at least semi-TCB.

If an attacker can't run code in your driver domain (and be aware of
things like server side processing, JIT of SQL, etc as "running code"
methods), they aren't in a position to mount an SP3 attack.

>  Would CPU pinning of an untrusted guest driver domain reduce its
> ability to attack the host?

All of SP1/2/3 can in principle be used to attack Xen, at which point
you have to presume that the entire system is readable.

CPU pinning can be used to prevent certain guests from sharing branch
prediction resources, and thus prevent them from directly attacking each
other using SP1 or SP2.

However, you can't isolate Xen away from the guest, so pinning is no
mitigation against attacks targeting Xen.

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

32bit PV guests are unable to use SP3 to attack Xen, but 32bit PV guest
userspace can still use SP3 to attack the guest kernel.

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 6661 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 2589 bytes --]

On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
> On 05/01/18 18:16, Rich Persaud wrote:
> >> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
> >> <mailto:lars.kurth.xen@gmail.com>> wrote:
> >> 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.  

Is some partial KPTI-like approach feasible? Like unmapping memory owned
by other guests, but keeping Xen areas mapped? This will still allow
leaking Xen memory, but there are very few secrets there (vCPUs state,
anything else?), so overall impact will be much lower.

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

There is one drawback of such approach: running PV will now require a
CPU with VT-x (or equivalent). I think this is a huge problem, ruining
the most important (or maybe the only, nowadays) advantage of PV versus
PVH or HVM.

> > Since PVH does not yet support PCI passthrough, are there other
> > recommended SP3 mitigations for 64-bit PV driver domains?
> 
> Lock them down?  Device driver domains, even if not fully trusted, are
> going to be part of the system and therefore at least semi-TCB.
> 
> If an attacker can't run code in your driver domain (and be aware of
> things like server side processing, JIT of SQL, etc as "running code"
> methods), they aren't in a position to mount an SP3 attack.

Well, the main reason why driver domains are used in Qubes OS is
assumption that it is not possible to really "lock them down", given
full OS (Linux) running inside and being exposed to the outside world
(having network adapters, USB controllers etc). There are so many
components running them, that for sure some of them are buggy. Just some
examples exploitable in the near past: DHCP client, Bluetooth stack.

If we'd believe that handling those devices exposed to the outside world
is "safe", we wouldn't use driver domains at all...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Andrew Cooper]

On 07/01/2018 15:00, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
>> On 05/01/18 18:16, Rich Persaud wrote:
>>>> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
>>>> <mailto:lars.kurth.xen@gmail.com>> wrote:
>>>> 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.  
> Is some partial KPTI-like approach feasible? Like unmapping memory owned
> by other guests, but keeping Xen areas mapped? This will still allow
> leaking Xen memory, but there are very few secrets there (vCPUs state,
> anything else?), so overall impact will be much lower.

Feasible> certainly not on a short timescale.

One issue which cropped up when discussing this option is that xenheap
allocations use the directmap mappings to function.  vmap regions are
another where we need to maintain permanent mappings to specific guest
frames.

Register state in struct vcpus, or stack frames including GPR content
are probably the most directly-interesting information to read, but
things like the console ring or grant frames might be equally lucrative.

>
>>>> 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.
> There is one drawback of such approach: running PV will now require a
> CPU with VT-x (or equivalent). I think this is a huge problem, ruining
> the most important (or maybe the only, nowadays) advantage of PV versus
> PVH or HVM.

HVM-capable hardware has been around for 12 years now, which means that
for a lot of people, this solution is a whole lot better than nothing.

I'm not suggesting that we give up on PV guests, but see the cover
letter for "x86: Prerequisite work for a Xen KAISER solution" which
discusses some of the challenges which need to be overcome.

>>> Since PVH does not yet support PCI passthrough, are there other
>>> recommended SP3 mitigations for 64-bit PV driver domains?
>> Lock them down?  Device driver domains, even if not fully trusted, are
>> going to be part of the system and therefore at least semi-TCB.
>>
>> If an attacker can't run code in your driver domain (and be aware of
>> things like server side processing, JIT of SQL, etc as "running code"
>> methods), they aren't in a position to mount an SP3 attack.
> Well, the main reason why driver domains are used in Qubes OS is
> assumption that it is not possible to really "lock them down", given
> full OS (Linux) running inside and being exposed to the outside world
> (having network adapters, USB controllers etc). There are so many
> components running them, that for sure some of them are buggy. Just some
> examples exploitable in the near past: DHCP client, Bluetooth stack.
>
> If we'd believe that handling those devices exposed to the outside world
> is "safe", we wouldn't use driver domains at all...

Indeed, but they are in a better position than arbitrary VMs, because
users can't just log into them and start running code.  (I really hope...)

~Andrew

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

Re: Xen Project Spectre/Meltdown FAQ

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 1666 bytes --]


> On 7 Jan 2018, at 17:11, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> 
> 
>>>> Since PVH does not yet support PCI passthrough, are there other
>>>> recommended SP3 mitigations for 64-bit PV driver domains?
>>> Lock them down?  Device driver domains, even if not fully trusted, are
>>> going to be part of the system and therefore at least semi-TCB.
>>> 
>>> If an attacker can't run code in your driver domain (and be aware of
>>> things like server side processing, JIT of SQL, etc as "running code"
>>> methods), they aren't in a position to mount an SP3 attack.
>> Well, the main reason why driver domains are used in Qubes OS is
>> assumption that it is not possible to really "lock them down", given
>> full OS (Linux) running inside and being exposed to the outside world
>> (having network adapters, USB controllers etc). There are so many
>> components running them, that for sure some of them are buggy. Just some
>> examples exploitable in the near past: DHCP client, Bluetooth stack.
>> 
>> If we'd believe that handling those devices exposed to the outside world
>> is "safe", we wouldn't use driver domains at all...
> 
> Indeed, but they are in a better position than arbitrary VMs, because
> users can't just log into them and start running code.  (I really hope...)


I wanted to point out https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00497.html <https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00497.html> which according to the cover letter is based on HVM and not PVH. I am not really sure whether this would solve some of the problems around PCI passthrough. 

Regards
Lars

[-- Attachment #1.2: Type: text/html, Size: 4924 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 8331 bytes --]

Hans,
I updated the FAQ on the blog. Thank you for your input. 
Lars

> On 5 Jan 2018, at 15:55, Hans van Kranenburg <hans@knorrie.org> 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/ <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@lists.xenproject.org <mailto:Xen-devel@lists.xenproject.org> 
>> https://lists.xenproject.org/mailman/listinfo/xen-devel <https://lists.xenproject.org/mailman/listinfo/xen-devel>

[-- Attachment #1.2: Type: text/html, Size: 33388 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Roger Pau Monné]

On Mon, Jan 08, 2018 at 09:02:37AM +0000, Lars Kurth wrote:
> 
> > On 7 Jan 2018, at 17:11, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > 
> > 
> >>>> Since PVH does not yet support PCI passthrough, are there other
> >>>> recommended SP3 mitigations for 64-bit PV driver domains?
> >>> Lock them down?  Device driver domains, even if not fully trusted, are
> >>> going to be part of the system and therefore at least semi-TCB.
> >>> 
> >>> If an attacker can't run code in your driver domain (and be aware of
> >>> things like server side processing, JIT of SQL, etc as "running code"
> >>> methods), they aren't in a position to mount an SP3 attack.
> >> Well, the main reason why driver domains are used in Qubes OS is
> >> assumption that it is not possible to really "lock them down", given
> >> full OS (Linux) running inside and being exposed to the outside world
> >> (having network adapters, USB controllers etc). There are so many
> >> components running them, that for sure some of them are buggy. Just some
> >> examples exploitable in the near past: DHCP client, Bluetooth stack.
> >> 
> >> If we'd believe that handling those devices exposed to the outside world
> >> is "safe", we wouldn't use driver domains at all...
> > 
> > Indeed, but they are in a better position than arbitrary VMs, because
> > users can't just log into them and start running code.  (I really hope...)
> 
> 
> I wanted to point out https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00497.html <https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00497.html> which according to the cover letter is based on HVM and not PVH. I am not really sure whether this would solve some of the problems around PCI passthrough. 

The pv-shim should also work inside an HVM guest, we just use PVH
because it's easier to setup from a toolstack PoV. The passthrough
problem is going to be the same with either PVH or HVM, which is that
the shim would have to provide something like pciback to the guest.

Roger.

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

Re: Xen Project Spectre/Meltdown FAQ

[George Dunlap]

On 01/07/2018 05:11 PM, Andrew Cooper wrote:
> On 07/01/2018 15:00, Marek Marczykowski-Górecki wrote:
>> On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
>>> On 05/01/18 18:16, Rich Persaud wrote:
>>>>> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
>>>>> <mailto:lars.kurth.xen@gmail.com>> wrote:
>>>>> 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.  
>> Is some partial KPTI-like approach feasible? Like unmapping memory owned
>> by other guests, but keeping Xen areas mapped? This will still allow
>> leaking Xen memory, but there are very few secrets there (vCPUs state,
>> anything else?), so overall impact will be much lower.
> 
> Feasible> certainly not on a short timescale.
> 
> One issue which cropped up when discussing this option is that xenheap
> allocations use the directmap mappings to function.  vmap regions are
> another where we need to maintain permanent mappings to specific guest
> frames.
> 
> Register state in struct vcpus, or stack frames including GPR content
> are probably the most directly-interesting information to read, but
> things like the console ring or grant frames might be equally lucrative.

That is to say, we are certainly working on solutions which will allow
PV guests to run in PV mode again.  Andrew posted an early draft of his
"KPTI-like solution" last week [1], and the solution you mention, of
essentially assuming that the guest can read hypervisor memory and
trying to make sure there's nothing there worth seeing, is being
discussed as well (in the same thread).

[1]
marc.info/?i=<1515097329-31902-1-git-send-email-andrew.cooper3@citrix.com>

 -George

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

Re: Xen Project Spectre/Meltdown FAQ

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 787 bytes --]

On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
> > On 05/01/18 18:16, Rich Persaud wrote:
> > >> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
> > >> <mailto:lars.kurth.xen@gmail.com>> wrote:
> > >> 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.  
> 
> Is some partial KPTI-like approach feasible? Like unmapping memory owned
> by other guests, but keeping Xen areas mapped? This will still allow
> leaking Xen memory, but there are very few secrets there (vCPUs state,
> anything else?), so overall impact will be much lower.

+1

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Peter]

On 2018-01-09 15:04, Stefano Stabellini wrote:
> On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
>> On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
>> > On 05/01/18 18:16, Rich Persaud wrote:
>> > >> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
>> > >> <mailto:lars.kurth.xen@gmail.com>> wrote:
>> > >> 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.  
>> 
>> Is some partial KPTI-like approach feasible? Like unmapping memory 
>> owned
>> by other guests, but keeping Xen areas mapped? This will still allow
>> leaking Xen memory, but there are very few secrets there (vCPUs state,
>> anything else?), so overall impact will be much lower.
> 
> +1
> 

I believe 
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ 
is clear re VMs attacking/accessing the host/dom0/hypervisor and the 
mitigations for that.

However the page seems ambiguous about whether 64 bit VMs running as 
PVHv2 with host provided kernels are protected or not (from each VM's 
own processes).

Can the page be updated to be more explicit and perhaps describe how the 
VM kernel or how the PVHv2 virtualization provides that protection.  And 
ideally how that could be checked from the VM itself.  e.g. grep pti 
/proc/cpuinfo?

e.g. the page says: "Guest kernels running in 64-bit PV mode are not 
directly vulnerable to attack using SP3, because 64-bit PV guests 
already run in a KPTI-like mode." but it does not mention PVHv2 for 
that.  Is it protected under PVHv2?  Does it depend on the kernel?  Is 
so what is the patchset/option/mechanism that protects the VM from its 
own processes?



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

Re: Xen Project Spectre/Meltdown FAQ

[Juergen Gross]

On 10/01/18 04:58, Peter wrote:
> On 2018-01-09 15:04, Stefano Stabellini wrote:
>> On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
>>> > On 05/01/18 18:16, Rich Persaud wrote:
>>> > >> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
>>> > >> <mailto:lars.kurth.xen@gmail.com>> wrote:
>>> > >> 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.  
>>>
>>> Is some partial KPTI-like approach feasible? Like unmapping memory owned
>>> by other guests, but keeping Xen areas mapped? This will still allow
>>> leaking Xen memory, but there are very few secrets there (vCPUs state,
>>> anything else?), so overall impact will be much lower.
>>
>> +1
>>
> 
> I believe
> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
> is clear re VMs attacking/accessing the host/dom0/hypervisor and the
> mitigations for that.
> 
> However the page seems ambiguous about whether 64 bit VMs running as
> PVHv2 with host provided kernels are protected or not (from each VM's
> own processes).

PVHv2 is using exactly the same runtime environment as HVM seen from the
hypervisor. So a guest running as PVHv2 needs a PTI like approach like
HVM in its kernel.

> Can the page be updated to be more explicit and perhaps describe how the
> VM kernel or how the PVHv2 virtualization provides that protection.  And
> ideally how that could be checked from the VM itself.  e.g. grep pti
> /proc/cpuinfo?

As this is really guest specific this information can't be provided by
Xen.

> e.g. the page says: "Guest kernels running in 64-bit PV mode are not
> directly vulnerable to attack using SP3, because 64-bit PV guests
> already run in a KPTI-like mode." but it does not mention PVHv2 for
> that.  Is it protected under PVHv2?  Does it depend on the kernel?  Is
> so what is the patchset/option/mechanism that protects the VM from its
> own processes?

This question should have been answered above already.


Juergen

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

Re: Xen Project Spectre/Meltdown FAQ

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 3347 bytes --]

I am wondering whether something like the attached table would make understanding the FAQ easier. Page 1 is clearly what is Xen specific and we definitely should cover.
Page 2 in general covers Linux and guests. The first block is relatively straightforward.

The 2nd and 3rd block is based on information from Doug: as there are many gaps, I would be uneasy about publishing these somewhere prominent. 

Also
> As this is really guest specific this information can't be provided by
> Xen.
which carries a risk that any analysis made by anyone might only apply to the context in which the analysis was done.

But the question keeps coming up, so making this clearer is maybe sensible.

Best Regards
Lars

> On 10 Jan 2018, at 06:03, Juergen Gross <jgross@suse.com> wrote:
> 
> On 10/01/18 04:58, Peter wrote:
>> On 2018-01-09 15:04, Stefano Stabellini wrote:
>>> On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
>>>> On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
>>>>> On 05/01/18 18:16, Rich Persaud wrote:
>>>>>>> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
>>>>>>> <mailto:lars.kurth.xen@gmail.com>> wrote:
>>>>>>> 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.  
>>>> 
>>>> Is some partial KPTI-like approach feasible? Like unmapping memory owned
>>>> by other guests, but keeping Xen areas mapped? This will still allow
>>>> leaking Xen memory, but there are very few secrets there (vCPUs state,
>>>> anything else?), so overall impact will be much lower.
>>> 
>>> +1
>>> 
>> 
>> I believe
>> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
>> is clear re VMs attacking/accessing the host/dom0/hypervisor and the
>> mitigations for that.
>> 
>> However the page seems ambiguous about whether 64 bit VMs running as
>> PVHv2 with host provided kernels are protected or not (from each VM's
>> own processes).
> 
> PVHv2 is using exactly the same runtime environment as HVM seen from the
> hypervisor. So a guest running as PVHv2 needs a PTI like approach like
> HVM in its kernel.
> 
>> Can the page be updated to be more explicit and perhaps describe how the
>> VM kernel or how the PVHv2 virtualization provides that protection.  And
>> ideally how that could be checked from the VM itself.  e.g. grep pti
>> /proc/cpuinfo?
> 
> As this is really guest specific this information can't be provided by
> Xen.
> 
>> e.g. the page says: "Guest kernels running in 64-bit PV mode are not
>> directly vulnerable to attack using SP3, because 64-bit PV guests
>> already run in a KPTI-like mode." but it does not mention PVHv2 for
>> that.  Is it protected under PVHv2?  Does it depend on the kernel?  Is
>> so what is the patchset/option/mechanism that protects the VM from its
>> own processes?
> 
> This question should have been answered above already.
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org <mailto:Xen-devel@lists.xenproject.org>
> https://lists.xenproject.org/mailman/listinfo/xen-devel <https://lists.xenproject.org/mailman/listinfo/xen-devel>

[-- Attachment #1.2: Type: text/html, Size: 15891 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 3716 bytes --]

And this time with attachment


> On 11 Jan 2018, at 09:15, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
> 
> I am wondering whether something like the attached table would make understanding the FAQ easier. Page 1 is clearly what is Xen specific and we definitely should cover.
> Page 2 in general covers Linux and guests. The first block is relatively straightforward.
> 
> The 2nd and 3rd block is based on information from Doug: as there are many gaps, I would be uneasy about publishing these somewhere prominent. 
> 
> Also
>> As this is really guest specific this information can't be provided by
>> Xen.
> which carries a risk that any analysis made by anyone might only apply to the context in which the analysis was done.
> 
> But the question keeps coming up, so making this clearer is maybe sensible.
> 
> Best Regards
> Lars
> 
>> On 10 Jan 2018, at 06:03, Juergen Gross <jgross@suse.com <mailto:jgross@suse.com>> wrote:
>> 
>> On 10/01/18 04:58, Peter wrote:
>>> On 2018-01-09 15:04, Stefano Stabellini wrote:
>>>> On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
>>>>> On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
>>>>>> On 05/01/18 18:16, Rich Persaud wrote:
>>>>>>>> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com <mailto:lars.kurth.xen@gmail.com>
>>>>>>>> <mailto:lars.kurth.xen@gmail.com <mailto:lars.kurth.xen@gmail.com>>> wrote:
>>>>>>>> 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.  
>>>>> 
>>>>> Is some partial KPTI-like approach feasible? Like unmapping memory owned
>>>>> by other guests, but keeping Xen areas mapped? This will still allow
>>>>> leaking Xen memory, but there are very few secrets there (vCPUs state,
>>>>> anything else?), so overall impact will be much lower.
>>>> 
>>>> +1
>>>> 
>>> 
>>> I believe
>>> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ <https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/>
>>> is clear re VMs attacking/accessing the host/dom0/hypervisor and the
>>> mitigations for that.
>>> 
>>> However the page seems ambiguous about whether 64 bit VMs running as
>>> PVHv2 with host provided kernels are protected or not (from each VM's
>>> own processes).
>> 
>> PVHv2 is using exactly the same runtime environment as HVM seen from the
>> hypervisor. So a guest running as PVHv2 needs a PTI like approach like
>> HVM in its kernel.
>> 
>>> Can the page be updated to be more explicit and perhaps describe how the
>>> VM kernel or how the PVHv2 virtualization provides that protection.  And
>>> ideally how that could be checked from the VM itself.  e.g. grep pti
>>> /proc/cpuinfo?
>> 
>> As this is really guest specific this information can't be provided by
>> Xen.
>> 
>>> e.g. the page says: "Guest kernels running in 64-bit PV mode are not
>>> directly vulnerable to attack using SP3, because 64-bit PV guests
>>> already run in a KPTI-like mode." but it does not mention PVHv2 for
>>> that.  Is it protected under PVHv2?  Does it depend on the kernel?  Is
>>> so what is the patchset/option/mechanism that protects the VM from its
>>> own processes?
>> 
>> This question should have been answered above already.
>> 
>> 
>> Juergen
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xenproject.org <mailto:Xen-devel@lists.xenproject.org>
>> https://lists.xenproject.org/mailman/listinfo/xen-devel <https://lists.xenproject.org/mailman/listinfo/xen-devel>


[-- Attachment #1.2.1: Type: text/html, Size: 259 bytes --]

[-- Attachment #1.2.2: Matrix.pdf --]
[-- Type: application/pdf, Size: 25055 bytes --]

[-- Attachment #1.2.3: Type: text/html, Size: 16387 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Hans van Kranenburg]

On 01/11/2018 10:15 AM, Lars Kurth wrote:
> I am wondering whether something like the attached table would make
> understanding the FAQ easier. Page 1 is clearly what is Xen specific and
> we definitely should cover.
> Page 2 in general covers Linux and guests. The first block is relatively
> straightforward.
> 
> The 2nd and 3rd block is based on information from Doug: as there are
> many gaps, I would be uneasy about publishing these somewhere prominent. 
> 
> Also
>> As this is really guest specific this information can't be provided by
>> Xen.
> which carries a risk that any analysis made by anyone might only apply
> to the context in which the analysis was done.
> 
> But the question keeps coming up, so making this clearer is maybe sensible.

Yes! This is a really good thing do do, since it's much more powerful
than trying to express the "multi-dimensional combinations" in  sentences.

When having this, the amount of text in the faq should just clearly
describe the categories, and cut out all the "X can but not if Y, but
also Y but not if Z" type sentences and then refer to the tables for the
end verdict for a specific users own situation.

  -- >8 --

The one thing I would want to point out again, which keeps to be a
non-obvious thing for users, is that in the short term with the pvshim
solution, a 64 bit PV guest in pvshim mode can still not be protected
against itself.

At  "Is a user space attack on the guest kernel possible (when running
in a Xen VM)"  there could be a [3] at 64 bit PV no, with the
explanation that while technically correct, this can again be
circumvented by exploiting the attack via Xen (see 'on other guest'
table) back to itself.

Or maybe adding an extra table "Is a user space attack via Xen back to
the guest itself possible (when running in a Xen VM)?" will help instead.

And to make it more complicated, a user would want to see how the tables
change when injecting the pvshim approach... For that, it might be
sufficient to add an extra row to all tables with "64 bit PV in pvhsim"
just below "64 bit PV".


Thanks,
Hans


[0] I also haven't see this info in any PR from AWS about PV guests?
Like, "hey, we protected ourselves and other customers against you, but
we can't do anything about your own business. Please stop using 64bit PV
instances for now if there's anything untrusted running inside."

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

Re: Xen Project Spectre/Meltdown FAQ

[Peter]

On 2018-01-11 22:16, Lars Kurth wrote:
> And this time with attachment
>> On 11 Jan 2018, at 09:15, Lars Kurth <lars.kurth.xen@gmail.com>
>> wrote:
>> 
>> I am wondering whether something like the attached table would make
>> understanding the FAQ easier. Page 1 is clearly what is Xen specific
>> and we definitely should cover.
>> Page 2 in general covers Linux and guests. The first block is
>> relatively straightforward.
>> 
>> The 2nd and 3rd block is based on information from Doug: as there
>> are many gaps, I would be uneasy about publishing these somewhere
>> prominent.
>> 
>> Also
>> 
>>> As this is really guest specific this information can't be
>>> provided by
>>> Xen.
>> 
>> which carries a risk that any analysis made by anyone might only
>> apply to the context in which the analysis was done.
>> 
>> But the question keeps coming up, so making this clearer is maybe
>> sensible.

In the matrix I see "Is a user space attack on the guest kernel possible 
(when running in a Xen VM)?" For PVH (and HVM) = Yes[1] where [1] 
Impacts Intel CPUs only.

Is there any mitigation for this?  i.e. How to protect a guest VM from 
its own userspace processes.

>> 
>> Best Regards
>> Lars
>> 
>> On 10 Jan 2018, at 06:03, Juergen Gross <jgross@suse.com> wrote:
>> On 10/01/18 04:58, Peter wrote:
>> On 2018-01-09 15:04, Stefano Stabellini wrote:
>> On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
>> On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
>> On 05/01/18 18:16, Rich Persaud wrote:
>> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
>> <mailto:lars.kurth.xen@gmail.com>> wrote:
>> 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.
> 
> Is some partial KPTI-like approach feasible? Like unmapping memory
> owned
> by other guests, but keeping Xen areas mapped? This will still allow
> leaking Xen memory, but there are very few secrets there (vCPUs state,
> anything else?), so overall impact will be much lower.
> 
> +1
> 
> I believe
> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
> is clear re VMs attacking/accessing the host/dom0/hypervisor and the
> mitigations for that.
> 
> However the page seems ambiguous about whether 64 bit VMs running as
> PVHv2 with host provided kernels are protected or not (from each VM's
> own processes).
> 
> PVHv2 is using exactly the same runtime environment as HVM seen from
> the
> hypervisor. So a guest running as PVHv2 needs a PTI like approach like
> HVM in its kernel.
> 
>> Can the page be updated to be more explicit and perhaps describe how
>> the
>> VM kernel or how the PVHv2 virtualization provides that protection.
>> And
>> ideally how that could be checked from the VM itself.  e.g. grep pti
>> /proc/cpuinfo?
> 
> As this is really guest specific this information can't be provided by
> Xen.
> 
>> e.g. the page says: "Guest kernels running in 64-bit PV mode are not
>> directly vulnerable to attack using SP3, because 64-bit PV guests
>> already run in a KPTI-like mode." but it does not mention PVHv2 for
>> that.  Is it protected under PVHv2?  Does it depend on the kernel?
>> Is
>> so what is the patchset/option/mechanism that protects the VM from
>> its
>> own processes?
> 
> This question should have been answered above already.
> 
> Juergen
> 

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

Re: Xen Project Spectre/Meltdown FAQ

[Hans van Kranenburg]

On 01/11/2018 08:22 PM, Peter wrote:
> On 2018-01-11 22:16, Lars Kurth wrote:
>> And this time with attachment
>>> On 11 Jan 2018, at 09:15, Lars Kurth <lars.kurth.xen@gmail.com>
>>> wrote:
>>>
>>> I am wondering whether something like the attached table would make
>>> understanding the FAQ easier. Page 1 is clearly what is Xen specific
>>> and we definitely should cover.
>>> Page 2 in general covers Linux and guests. The first block is
>>> relatively straightforward.
>>>
>>> The 2nd and 3rd block is based on information from Doug: as there
>>> are many gaps, I would be uneasy about publishing these somewhere
>>> prominent.
>>>
>>> Also
>>>
>>>> As this is really guest specific this information can't be
>>>> provided by
>>>> Xen.
>>>
>>> which carries a risk that any analysis made by anyone might only
>>> apply to the context in which the analysis was done.
>>>
>>> But the question keeps coming up, so making this clearer is maybe
>>> sensible.
> 
> In the matrix I see "Is a user space attack on the guest kernel possible
> (when running in a Xen VM)?" For PVH (and HVM) = Yes[1] where [1]
> Impacts Intel CPUs only.
> 
> Is there any mitigation for this?  i.e. How to protect a guest VM from
> its own userspace processes.

That part is handled by the kernel inside the guest. Xen doesn't see
that happening.

It's for example the KPTI/KAISER patches that got into the linux kernels
now.

>>>
>>> Best Regards
>>> Lars
>>>
>>> On 10 Jan 2018, at 06:03, Juergen Gross <jgross@suse.com> wrote:
>>> On 10/01/18 04:58, Peter wrote:
>>> On 2018-01-09 15:04, Stefano Stabellini wrote:
>>> On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
>>> On 05/01/18 18:16, Rich Persaud wrote:
>>> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
>>> <mailto:lars.kurth.xen@gmail.com>> wrote:
>>> 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.
>>
>> Is some partial KPTI-like approach feasible? Like unmapping memory
>> owned
>> by other guests, but keeping Xen areas mapped? This will still allow
>> leaking Xen memory, but there are very few secrets there (vCPUs state,
>> anything else?), so overall impact will be much lower.
>>
>> +1
>>
>> I believe
>> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
>> is clear re VMs attacking/accessing the host/dom0/hypervisor and the
>> mitigations for that.
>>
>> However the page seems ambiguous about whether 64 bit VMs running as
>> PVHv2 with host provided kernels are protected or not (from each VM's
>> own processes).
>>
>> PVHv2 is using exactly the same runtime environment as HVM seen from
>> the
>> hypervisor. So a guest running as PVHv2 needs a PTI like approach like
>> HVM in its kernel.
>>
>>> Can the page be updated to be more explicit and perhaps describe how
>>> the
>>> VM kernel or how the PVHv2 virtualization provides that protection.
>>> And
>>> ideally how that could be checked from the VM itself.  e.g. grep pti
>>> /proc/cpuinfo?
>>
>> As this is really guest specific this information can't be provided by
>> Xen.
>>
>>> e.g. the page says: "Guest kernels running in 64-bit PV mode are not
>>> directly vulnerable to attack using SP3, because 64-bit PV guests
>>> already run in a KPTI-like mode." but it does not mention PVHv2 for
>>> that.  Is it protected under PVHv2?  Does it depend on the kernel?
>>> Is
>>> so what is the patchset/option/mechanism that protects the VM from
>>> its
>>> own processes?
>>
>> This question should have been answered above already.
>>
>> Juergen
>>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


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

Re: Xen Project Spectre/Meltdown FAQ

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 1041 bytes --]

On 1/11/18 3:16 AM, Lars Kurth wrote:
> And this time with attachment
> 
> 
> 
>> On 11 Jan 2018, at 09:15, Lars Kurth <lars.kurth.xen@gmail.com
>> <mailto:lars.kurth.xen@gmail.com>> wrote:
>>
>> I am wondering whether something like the attached table would make
>> understanding the FAQ easier. Page 1 is clearly what is Xen specific
>> and we definitely should cover.
>> Page 2 in general covers Linux and guests. The first block is
>> relatively straightforward.
>>
>> The 2nd and 3rd block is based on information from Doug: as there are
>> many gaps, I would be uneasy about publishing these somewhere prominent. 
>>
>> Also
>>> As this is really guest specific this information can't be provided by
>>> Xen.
>> which carries a risk that any analysis made by anyone might only apply
>> to the context in which the analysis was done.
>>
>> But the question keeps coming up, so making this clearer is maybe
>> sensible.
>>
>> Best Regards
>> Lars

Thanks for the improvements Lars.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Xen Project Spectre/Meltdown FAQ

[Nathan March]

> > In the matrix I see "Is a user space attack on the guest kernel possible
> > (when running in a Xen VM)?" For PVH (and HVM) = Yes[1] where [1]
> > Impacts Intel CPUs only.
> >
> > Is there any mitigation for this?  i.e. How to protect a guest VM from
> > its own userspace processes.
> 
> That part is handled by the kernel inside the guest. Xen doesn't see
> that happening.
> 
> It's for example the KPTI/KAISER patches that got into the linux kernels
> now.

The most recent update to XSA-254 seems to clearly state that the kernel KPTI patches will not protect the guest from itself with the shim installed:

> PV-in-PVH/HVM shim approach leaves *guest* vulnerable to Meltdown
> attacks from its unprivileged users, even if the guest has KPTI
> patches.  That is, guest userspace can use Meltdown to read all memory
> in the same guest.

So the questions remains, how do you protect a guest from a malicious user inside of it?

Is it really the case that the *only* full solution to move to xen 4.10 and guest kernel 4.11?!

Cheers,
Nathan


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

Re: Xen Project Spectre/Meltdown FAQ

[Andrew Cooper]

On 12/01/18 17:17, Nathan March wrote:
>>> In the matrix I see "Is a user space attack on the guest kernel possible
>>> (when running in a Xen VM)?" For PVH (and HVM) = Yes[1] where [1]
>>> Impacts Intel CPUs only.
>>>
>>> Is there any mitigation for this?  i.e. How to protect a guest VM from
>>> its own userspace processes.
>> That part is handled by the kernel inside the guest. Xen doesn't see
>> that happening.
>>
>> It's for example the KPTI/KAISER patches that got into the linux kernels
>> now.
> The most recent update to XSA-254 seems to clearly state that the kernel KPTI patches will not protect the guest from itself with the shim installed:
>
>> PV-in-PVH/HVM shim approach leaves *guest* vulnerable to Meltdown
>> attacks from its unprivileged users, even if the guest has KPTI
>> patches.  That is, guest userspace can use Meltdown to read all memory
>> in the same guest.
> So the questions remains, how do you protect a guest from a malicious user inside of it?

Switch it to being an HVM/PVH guest, and use Linux's KPTI, or wait to
see if we can sensibly implement XPTI.

A PV executes just like a userspace process under native Linux.  The
architecture means that Xen owns the pagetables, but that the guest
kernel controls the content (albeit, audited) of the pagetables.

A full and proper fix for SP3/Meltdown for PV guests can only come from
a change in Xen.  Otherwise, it is like expecting that a change in
systemd would be able to make your native system secure to SP3/Meltdown.

~Andrew

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