linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Mention PowerPC in the L1TF documentation.
@ 2019-11-14 22:16 asteinhauser
  2019-11-14 22:55 ` Thomas Gleixner
  0 siblings, 1 reply; 5+ messages in thread
From: asteinhauser @ 2019-11-14 22:16 UTC (permalink / raw)
  To: corbet, tglx; +Cc: linux-doc, Anthony Steinhauser

From: Anthony Steinhauser <asteinhauser@google.com>

There is a false negative that L1TF is Intel specific while it affects
also PowerPC:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d
Another false negative is that the kernel is unconditionally protected
against L1TF attacks from userspace. That's true only on x86 but not on
PowerPC where you can turn the protection off by nopti.
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
---
 Documentation/admin-guide/hw-vuln/l1tf.rst | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/Documentation/admin-guide/hw-vuln/l1tf.rst b/Documentation/admin-guide/hw-vuln/l1tf.rst
index f83212fae4d5..243e494b337a 100644
--- a/Documentation/admin-guide/hw-vuln/l1tf.rst
+++ b/Documentation/admin-guide/hw-vuln/l1tf.rst
@@ -9,10 +9,11 @@ for the access, has the Present bit cleared or other reserved bits set.
 Affected processors
 -------------------
 
-This vulnerability affects a wide range of Intel processors. The
-vulnerability is not present on:
+This vulnerability affects a wide range of Intel and PowerPC processors.
+The vulnerability is not present on:
 
-   - Processors from AMD, Centaur and other non Intel vendors
+   - Processors from AMD, Centaur and other non Intel vendors except for
+     PowerPC
 
    - Older processor models, where the CPU family is < 6
 
@@ -125,7 +126,7 @@ mitigations are active. The relevant sysfs file is:
 
 /sys/devices/system/cpu/vulnerabilities/l1tf
 
-The possible values in this file are:
+The possible values in this file on x86 are:
 
   ===========================   ===============================
   'Not affected'		The processor is not vulnerable
@@ -158,8 +159,10 @@ The resulting grade of protection is discussed in the following sections.
 Host mitigation mechanism
 -------------------------
 
-The kernel is unconditionally protected against L1TF attacks from malicious
-user space running on the host.
+On x86 the kernel is unconditionally protected against L1TF attacks from
+malicious user space running on the host. On PowerPC the kernel is
+protected by flushing the L1D cache on each transition from kernel to
+userspace unless the 'nopti' boot argument turns this mitigation off.
 
 
 Guest mitigation mechanisms
-- 
2.24.0.432.g9d3f5f5b63-goog


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] Mention PowerPC in the L1TF documentation.
  2019-11-14 22:16 [PATCH] Mention PowerPC in the L1TF documentation asteinhauser
@ 2019-11-14 22:55 ` Thomas Gleixner
  2019-11-14 23:14   ` Anthony Steinhauser
  0 siblings, 1 reply; 5+ messages in thread
From: Thomas Gleixner @ 2019-11-14 22:55 UTC (permalink / raw)
  To: Anthony Steinhauser
  Cc: Jonathan Corbet, linux-doc, Jiri Kosina, Michael Ellerman

Anthony,

On Thu, 14 Nov 2019, asteinhauser@google.com wrote:

> From: Anthony Steinhauser <asteinhauser@google.com>
> 
> There is a false negative that L1TF is Intel specific while it affects
> also PowerPC:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d

Please use the regular

   commit 12-char-sha ("powerpc: .......")

notation. These links are horrible.

> Another false negative is that the kernel is unconditionally protected
> against L1TF attacks from userspace. That's true only on x86 but not on
> PowerPC where you can turn the protection off by nopti.

Missing newline between body and SOB

> Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
> ---
>  Documentation/admin-guide/hw-vuln/l1tf.rst | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/admin-guide/hw-vuln/l1tf.rst b/Documentation/admin-guide/hw-vuln/l1tf.rst
> index f83212fae4d5..243e494b337a 100644
> --- a/Documentation/admin-guide/hw-vuln/l1tf.rst
> +++ b/Documentation/admin-guide/hw-vuln/l1tf.rst
> @@ -9,10 +9,11 @@ for the access, has the Present bit cleared or other reserved bits set.
>  Affected processors
>  -------------------
>  
> -This vulnerability affects a wide range of Intel processors. The
> -vulnerability is not present on:
> +This vulnerability affects a wide range of Intel and PowerPC processors.
> +The vulnerability is not present on:
>  
> -   - Processors from AMD, Centaur and other non Intel vendors
> +   - Processors from AMD, Centaur and other non Intel vendors except for
> +     PowerPC

No. This needs restructuring. The non Intel vendor means vendors which
produce x86 machines (not really clear TBH), but adding these two PPC parts
above and here does not make it any better.
  
>     - Older processor models, where the CPU family is < 6

Also this suggest that _ALL_ PowerPC processors are affected as there is
no exception list.

So I suggest to structure this like this:

Affected processors
-------------------

 1) Intel processors

    Move the existing list here

 2) PowerPC processors

    Add some meat

Whether a processor is affected or not...

> @@ -125,7 +126,7 @@ mitigations are active. The relevant sysfs file is:
>  
>  /sys/devices/system/cpu/vulnerabilities/l1tf
>  
> -The possible values in this file are:
> +The possible values in this file on x86 are:

That commit you referenced added the sysfs output for powerpc. So that
should be documented properly here as well, right?

>    ===========================   ===============================
>    'Not affected'		The processor is not vulnerable
> @@ -158,8 +159,10 @@ The resulting grade of protection is discussed in the following sections.
>  Host mitigation mechanism
>  -------------------------
>  
> -The kernel is unconditionally protected against L1TF attacks from malicious
> -user space running on the host.
> +On x86 the kernel is unconditionally protected against L1TF attacks from
> +malicious user space running on the host. On PowerPC the kernel is
> +protected by flushing the L1D cache on each transition from kernel to
> +userspace unless the 'nopti' boot argument turns this mitigation off.

Please make this clearly visually separated. Just glueing this together is
hard to read.

What about the l1tf boot param? Is it x86 only? If so, then this wants to
be added to the the documentation as well.

What about the guest to host issue on PPC? Not affected or same mitigation
or what?

We really spent a lot of time to write understandable and useful
documentation. Just sprinkling a few powerpc'isms into it is really not
cutting it.

This needs proper structuring so that it's obvious for the intended
audience (administrators, users) which part is applicable to which
architecture or to both. 

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Mention PowerPC in the L1TF documentation.
  2019-11-14 22:55 ` Thomas Gleixner
@ 2019-11-14 23:14   ` Anthony Steinhauser
  2019-11-15 11:41     ` Michael Ellerman
  0 siblings, 1 reply; 5+ messages in thread
From: Anthony Steinhauser @ 2019-11-14 23:14 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Jonathan Corbet, linux-doc, Jiri Kosina, Michael Ellerman

OK, I don't intend to work on it to that extent, so you can consider
this abandoned.

On Thu, Nov 14, 2019 at 2:55 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Anthony,
>
> On Thu, 14 Nov 2019, asteinhauser@google.com wrote:
>
> > From: Anthony Steinhauser <asteinhauser@google.com>
> >
> > There is a false negative that L1TF is Intel specific while it affects
> > also PowerPC:
> > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d
>
> Please use the regular
>
>    commit 12-char-sha ("powerpc: .......")
>
> notation. These links are horrible.
>
> > Another false negative is that the kernel is unconditionally protected
> > against L1TF attacks from userspace. That's true only on x86 but not on
> > PowerPC where you can turn the protection off by nopti.
>
> Missing newline between body and SOB
>
> > Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
> > ---
> >  Documentation/admin-guide/hw-vuln/l1tf.rst | 15 +++++++++------
> >  1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/hw-vuln/l1tf.rst b/Documentation/admin-guide/hw-vuln/l1tf.rst
> > index f83212fae4d5..243e494b337a 100644
> > --- a/Documentation/admin-guide/hw-vuln/l1tf.rst
> > +++ b/Documentation/admin-guide/hw-vuln/l1tf.rst
> > @@ -9,10 +9,11 @@ for the access, has the Present bit cleared or other reserved bits set.
> >  Affected processors
> >  -------------------
> >
> > -This vulnerability affects a wide range of Intel processors. The
> > -vulnerability is not present on:
> > +This vulnerability affects a wide range of Intel and PowerPC processors.
> > +The vulnerability is not present on:
> >
> > -   - Processors from AMD, Centaur and other non Intel vendors
> > +   - Processors from AMD, Centaur and other non Intel vendors except for
> > +     PowerPC
>
> No. This needs restructuring. The non Intel vendor means vendors which
> produce x86 machines (not really clear TBH), but adding these two PPC parts
> above and here does not make it any better.
>
> >     - Older processor models, where the CPU family is < 6
>
> Also this suggest that _ALL_ PowerPC processors are affected as there is
> no exception list.
>
> So I suggest to structure this like this:
>
> Affected processors
> -------------------
>
>  1) Intel processors
>
>     Move the existing list here
>
>  2) PowerPC processors
>
>     Add some meat
>
> Whether a processor is affected or not...
>
> > @@ -125,7 +126,7 @@ mitigations are active. The relevant sysfs file is:
> >
> >  /sys/devices/system/cpu/vulnerabilities/l1tf
> >
> > -The possible values in this file are:
> > +The possible values in this file on x86 are:
>
> That commit you referenced added the sysfs output for powerpc. So that
> should be documented properly here as well, right?
>
> >    ===========================   ===============================
> >    'Not affected'             The processor is not vulnerable
> > @@ -158,8 +159,10 @@ The resulting grade of protection is discussed in the following sections.
> >  Host mitigation mechanism
> >  -------------------------
> >
> > -The kernel is unconditionally protected against L1TF attacks from malicious
> > -user space running on the host.
> > +On x86 the kernel is unconditionally protected against L1TF attacks from
> > +malicious user space running on the host. On PowerPC the kernel is
> > +protected by flushing the L1D cache on each transition from kernel to
> > +userspace unless the 'nopti' boot argument turns this mitigation off.
>
> Please make this clearly visually separated. Just glueing this together is
> hard to read.
>
> What about the l1tf boot param? Is it x86 only? If so, then this wants to
> be added to the the documentation as well.
>
> What about the guest to host issue on PPC? Not affected or same mitigation
> or what?
>
> We really spent a lot of time to write understandable and useful
> documentation. Just sprinkling a few powerpc'isms into it is really not
> cutting it.
>
> This needs proper structuring so that it's obvious for the intended
> audience (administrators, users) which part is applicable to which
> architecture or to both.
>
> Thanks,
>
>         tglx

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Mention PowerPC in the L1TF documentation.
  2019-11-14 23:14   ` Anthony Steinhauser
@ 2019-11-15 11:41     ` Michael Ellerman
  2019-11-15 21:13       ` Anthony Steinhauser
  0 siblings, 1 reply; 5+ messages in thread
From: Michael Ellerman @ 2019-11-15 11:41 UTC (permalink / raw)
  To: Anthony Steinhauser, Thomas Gleixner
  Cc: Jonathan Corbet, linux-doc, Jiri Kosina

Anthony Steinhauser <asteinhauser@google.com> writes:
> OK, I don't intend to work on it to that extent, so you can consider
> this abandoned.

I or someone else at IBM will pick this up and get it massaged into a
form that Thomas is happy with.

cheers

> On Thu, Nov 14, 2019 at 2:55 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> Anthony,
>>
>> On Thu, 14 Nov 2019, asteinhauser@google.com wrote:
>>
>> > From: Anthony Steinhauser <asteinhauser@google.com>
>> >
>> > There is a false negative that L1TF is Intel specific while it affects
>> > also PowerPC:
>> > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d
>>
>> Please use the regular
>>
>>    commit 12-char-sha ("powerpc: .......")
>>
>> notation. These links are horrible.
>>
>> > Another false negative is that the kernel is unconditionally protected
>> > against L1TF attacks from userspace. That's true only on x86 but not on
>> > PowerPC where you can turn the protection off by nopti.
>>
>> Missing newline between body and SOB
>>
>> > Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
>> > ---
>> >  Documentation/admin-guide/hw-vuln/l1tf.rst | 15 +++++++++------
>> >  1 file changed, 9 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/Documentation/admin-guide/hw-vuln/l1tf.rst b/Documentation/admin-guide/hw-vuln/l1tf.rst
>> > index f83212fae4d5..243e494b337a 100644
>> > --- a/Documentation/admin-guide/hw-vuln/l1tf.rst
>> > +++ b/Documentation/admin-guide/hw-vuln/l1tf.rst
>> > @@ -9,10 +9,11 @@ for the access, has the Present bit cleared or other reserved bits set.
>> >  Affected processors
>> >  -------------------
>> >
>> > -This vulnerability affects a wide range of Intel processors. The
>> > -vulnerability is not present on:
>> > +This vulnerability affects a wide range of Intel and PowerPC processors.
>> > +The vulnerability is not present on:
>> >
>> > -   - Processors from AMD, Centaur and other non Intel vendors
>> > +   - Processors from AMD, Centaur and other non Intel vendors except for
>> > +     PowerPC
>>
>> No. This needs restructuring. The non Intel vendor means vendors which
>> produce x86 machines (not really clear TBH), but adding these two PPC parts
>> above and here does not make it any better.
>>
>> >     - Older processor models, where the CPU family is < 6
>>
>> Also this suggest that _ALL_ PowerPC processors are affected as there is
>> no exception list.
>>
>> So I suggest to structure this like this:
>>
>> Affected processors
>> -------------------
>>
>>  1) Intel processors
>>
>>     Move the existing list here
>>
>>  2) PowerPC processors
>>
>>     Add some meat
>>
>> Whether a processor is affected or not...
>>
>> > @@ -125,7 +126,7 @@ mitigations are active. The relevant sysfs file is:
>> >
>> >  /sys/devices/system/cpu/vulnerabilities/l1tf
>> >
>> > -The possible values in this file are:
>> > +The possible values in this file on x86 are:
>>
>> That commit you referenced added the sysfs output for powerpc. So that
>> should be documented properly here as well, right?
>>
>> >    ===========================   ===============================
>> >    'Not affected'             The processor is not vulnerable
>> > @@ -158,8 +159,10 @@ The resulting grade of protection is discussed in the following sections.
>> >  Host mitigation mechanism
>> >  -------------------------
>> >
>> > -The kernel is unconditionally protected against L1TF attacks from malicious
>> > -user space running on the host.
>> > +On x86 the kernel is unconditionally protected against L1TF attacks from
>> > +malicious user space running on the host. On PowerPC the kernel is
>> > +protected by flushing the L1D cache on each transition from kernel to
>> > +userspace unless the 'nopti' boot argument turns this mitigation off.
>>
>> Please make this clearly visually separated. Just glueing this together is
>> hard to read.
>>
>> What about the l1tf boot param? Is it x86 only? If so, then this wants to
>> be added to the the documentation as well.
>>
>> What about the guest to host issue on PPC? Not affected or same mitigation
>> or what?
>>
>> We really spent a lot of time to write understandable and useful
>> documentation. Just sprinkling a few powerpc'isms into it is really not
>> cutting it.
>>
>> This needs proper structuring so that it's obvious for the intended
>> audience (administrators, users) which part is applicable to which
>> architecture or to both.
>>
>> Thanks,
>>
>>         tglx

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Mention PowerPC in the L1TF documentation.
  2019-11-15 11:41     ` Michael Ellerman
@ 2019-11-15 21:13       ` Anthony Steinhauser
  0 siblings, 0 replies; 5+ messages in thread
From: Anthony Steinhauser @ 2019-11-15 21:13 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: Thomas Gleixner, Jonathan Corbet, linux-doc, Jiri Kosina

Thanks a lot, Michael!

On Fri, Nov 15, 2019 at 3:41 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Anthony Steinhauser <asteinhauser@google.com> writes:
> > OK, I don't intend to work on it to that extent, so you can consider
> > this abandoned.
>
> I or someone else at IBM will pick this up and get it massaged into a
> form that Thomas is happy with.
>
> cheers
>
> > On Thu, Nov 14, 2019 at 2:55 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> >>
> >> Anthony,
> >>
> >> On Thu, 14 Nov 2019, asteinhauser@google.com wrote:
> >>
> >> > From: Anthony Steinhauser <asteinhauser@google.com>
> >> >
> >> > There is a false negative that L1TF is Intel specific while it affects
> >> > also PowerPC:
> >> > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d
> >>
> >> Please use the regular
> >>
> >>    commit 12-char-sha ("powerpc: .......")
> >>
> >> notation. These links are horrible.
> >>
> >> > Another false negative is that the kernel is unconditionally protected
> >> > against L1TF attacks from userspace. That's true only on x86 but not on
> >> > PowerPC where you can turn the protection off by nopti.
> >>
> >> Missing newline between body and SOB
> >>
> >> > Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
> >> > ---
> >> >  Documentation/admin-guide/hw-vuln/l1tf.rst | 15 +++++++++------
> >> >  1 file changed, 9 insertions(+), 6 deletions(-)
> >> >
> >> > diff --git a/Documentation/admin-guide/hw-vuln/l1tf.rst b/Documentation/admin-guide/hw-vuln/l1tf.rst
> >> > index f83212fae4d5..243e494b337a 100644
> >> > --- a/Documentation/admin-guide/hw-vuln/l1tf.rst
> >> > +++ b/Documentation/admin-guide/hw-vuln/l1tf.rst
> >> > @@ -9,10 +9,11 @@ for the access, has the Present bit cleared or other reserved bits set.
> >> >  Affected processors
> >> >  -------------------
> >> >
> >> > -This vulnerability affects a wide range of Intel processors. The
> >> > -vulnerability is not present on:
> >> > +This vulnerability affects a wide range of Intel and PowerPC processors.
> >> > +The vulnerability is not present on:
> >> >
> >> > -   - Processors from AMD, Centaur and other non Intel vendors
> >> > +   - Processors from AMD, Centaur and other non Intel vendors except for
> >> > +     PowerPC
> >>
> >> No. This needs restructuring. The non Intel vendor means vendors which
> >> produce x86 machines (not really clear TBH), but adding these two PPC parts
> >> above and here does not make it any better.
> >>
> >> >     - Older processor models, where the CPU family is < 6
> >>
> >> Also this suggest that _ALL_ PowerPC processors are affected as there is
> >> no exception list.
> >>
> >> So I suggest to structure this like this:
> >>
> >> Affected processors
> >> -------------------
> >>
> >>  1) Intel processors
> >>
> >>     Move the existing list here
> >>
> >>  2) PowerPC processors
> >>
> >>     Add some meat
> >>
> >> Whether a processor is affected or not...
> >>
> >> > @@ -125,7 +126,7 @@ mitigations are active. The relevant sysfs file is:
> >> >
> >> >  /sys/devices/system/cpu/vulnerabilities/l1tf
> >> >
> >> > -The possible values in this file are:
> >> > +The possible values in this file on x86 are:
> >>
> >> That commit you referenced added the sysfs output for powerpc. So that
> >> should be documented properly here as well, right?
> >>
> >> >    ===========================   ===============================
> >> >    'Not affected'             The processor is not vulnerable
> >> > @@ -158,8 +159,10 @@ The resulting grade of protection is discussed in the following sections.
> >> >  Host mitigation mechanism
> >> >  -------------------------
> >> >
> >> > -The kernel is unconditionally protected against L1TF attacks from malicious
> >> > -user space running on the host.
> >> > +On x86 the kernel is unconditionally protected against L1TF attacks from
> >> > +malicious user space running on the host. On PowerPC the kernel is
> >> > +protected by flushing the L1D cache on each transition from kernel to
> >> > +userspace unless the 'nopti' boot argument turns this mitigation off.
> >>
> >> Please make this clearly visually separated. Just glueing this together is
> >> hard to read.
> >>
> >> What about the l1tf boot param? Is it x86 only? If so, then this wants to
> >> be added to the the documentation as well.
> >>
> >> What about the guest to host issue on PPC? Not affected or same mitigation
> >> or what?
> >>
> >> We really spent a lot of time to write understandable and useful
> >> documentation. Just sprinkling a few powerpc'isms into it is really not
> >> cutting it.
> >>
> >> This needs proper structuring so that it's obvious for the intended
> >> audience (administrators, users) which part is applicable to which
> >> architecture or to both.
> >>
> >> Thanks,
> >>
> >>         tglx

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-11-15 21:14 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-14 22:16 [PATCH] Mention PowerPC in the L1TF documentation asteinhauser
2019-11-14 22:55 ` Thomas Gleixner
2019-11-14 23:14   ` Anthony Steinhauser
2019-11-15 11:41     ` Michael Ellerman
2019-11-15 21:13       ` Anthony Steinhauser

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).