[patch] Fix up l1ft documentation was Re: Taking a break - time to look back

[patch] Fix up l1ft documentation was Re: Taking a break - time to look back

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 3809 bytes --]

Hi!

> The next round of speculation-related issues including the scary L1TF
> hardware bug was a way more "pleasant" experience to work on. While for
> obvious reasons the mitigation development happened behind closed doors in
> a smaller group of people, we were at least able to collaborate in a way
> which is somehow close to what we are used to.

Ok, I guess L1TF was a lot of fun, and there was not time for a good
documentation.

There's admin guide that is written as an advertisment, and
unfortunately is slightly "inaccurate" at places (to the point of
lying).

Plus, I believe it should go to x86/ directory, as this is really
Intel issue, and not anything ARM (or RISC-V) people need to
know. (But we already have some urls in printk messages that may need
fixing up..?)

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/Documentation/admin-guide/l1tf.rst b/Documentation/admin-guide/l1tf.rst
index b85dd80..05c5422 100644
--- a/Documentation/admin-guide/l1tf.rst
+++ b/Documentation/admin-guide/l1tf.rst
@@ -1,10 +1,11 @@
 L1TF - L1 Terminal Fault
 ========================
 
-L1 Terminal Fault is a hardware vulnerability which allows unprivileged
-speculative access to data which is available in the Level 1 Data Cache
-when the page table entry controlling the virtual address, which is used
-for the access, has the Present bit cleared or other reserved bits set.
+L1 Terminal Fault is a hardware vulnerability on most recent Intel x86
+CPUs which allows unprivileged speculative access to data which is
+available in the Level 1 Data Cache when the page table entry
+controlling the virtual address, which is used for the access, has the
+Present bit cleared or other reserved bits set.
 
 Affected processors
 -------------------
@@ -76,12 +77,14 @@ Attack scenarios
    deterministic and more practical.
 
    The Linux kernel contains a mitigation for this attack vector, PTE
-   inversion, which is permanently enabled and has no performance
-   impact. The kernel ensures that the address bits of PTEs, which are not
-   marked present, never point to cacheable physical memory space.
+   inversion, which is permanently enabled and has no measurable
+   performance impact in most configurations. The kernel ensures that
+   the address bits of PTEs, which are not marked present, never point
+   to cacheable physical memory space. On x86-32, this physical memory
+   needs to be limited to 2GiB to make mitigation effective.
 
-   A system with an up to date kernel is protected against attacks from
-   malicious user space applications.
+   Mitigation is present in kernels v4.19 and newer, and in
+   recent -stable kernels.
 
 2. Malicious guest in a virtual machine
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -405,6 +408,9 @@ time with the option "l1tf=". The valid arguments for this option are:
 
   off		Disables hypervisor mitigations and doesn't emit any
 		warnings.
+		It also drops the swap size and available RAM limit restrictions
+		on both hypervisor and bare metal.
+
   ============  =============================================================
 
 The default is 'flush'. For details about L1D flushing see :ref:`l1d_flush`.
@@ -576,7 +582,8 @@ Default mitigations
   The kernel default mitigations for vulnerable processors are:
 
   - PTE inversion to protect against malicious user space. This is done
-    unconditionally and cannot be controlled.
+    unconditionally and cannot be controlled. The swap storage is limited
+    to ~16TB.
 
   - L1D conditional flushing on VMENTER when EPT is enabled for
     a guest.




-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [patch] Fix up l1ft documentation was Re: Taking a break - time to look back

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 4094 bytes --]

Ping? Jonathan, can you pick this up?

								Pavel

On Thu 2019-01-03 00:51:52, Pavel Machek wrote:
> Hi!
> 
> > The next round of speculation-related issues including the scary L1TF
> > hardware bug was a way more "pleasant" experience to work on. While for
> > obvious reasons the mitigation development happened behind closed doors in
> > a smaller group of people, we were at least able to collaborate in a way
> > which is somehow close to what we are used to.
> 
> Ok, I guess L1TF was a lot of fun, and there was not time for a good
> documentation.
> 
> There's admin guide that is written as an advertisment, and
> unfortunately is slightly "inaccurate" at places (to the point of
> lying).
> 
> Plus, I believe it should go to x86/ directory, as this is really
> Intel issue, and not anything ARM (or RISC-V) people need to
> know. (But we already have some urls in printk messages that may need
> fixing up..?)
> 
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> diff --git a/Documentation/admin-guide/l1tf.rst b/Documentation/admin-guide/l1tf.rst
> index b85dd80..05c5422 100644
> --- a/Documentation/admin-guide/l1tf.rst
> +++ b/Documentation/admin-guide/l1tf.rst
> @@ -1,10 +1,11 @@
>  L1TF - L1 Terminal Fault
>  ========================
>  
> -L1 Terminal Fault is a hardware vulnerability which allows unprivileged
> -speculative access to data which is available in the Level 1 Data Cache
> -when the page table entry controlling the virtual address, which is used
> -for the access, has the Present bit cleared or other reserved bits set.
> +L1 Terminal Fault is a hardware vulnerability on most recent Intel x86
> +CPUs which allows unprivileged speculative access to data which is
> +available in the Level 1 Data Cache when the page table entry
> +controlling the virtual address, which is used for the access, has the
> +Present bit cleared or other reserved bits set.
>  
>  Affected processors
>  -------------------
> @@ -76,12 +77,14 @@ Attack scenarios
>     deterministic and more practical.
>  
>     The Linux kernel contains a mitigation for this attack vector, PTE
> -   inversion, which is permanently enabled and has no performance
> -   impact. The kernel ensures that the address bits of PTEs, which are not
> -   marked present, never point to cacheable physical memory space.
> +   inversion, which is permanently enabled and has no measurable
> +   performance impact in most configurations. The kernel ensures that
> +   the address bits of PTEs, which are not marked present, never point
> +   to cacheable physical memory space. On x86-32, this physical memory
> +   needs to be limited to 2GiB to make mitigation effective.
>  
> -   A system with an up to date kernel is protected against attacks from
> -   malicious user space applications.
> +   Mitigation is present in kernels v4.19 and newer, and in
> +   recent -stable kernels.
>  
>  2. Malicious guest in a virtual machine
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> @@ -405,6 +408,9 @@ time with the option "l1tf=". The valid arguments for this option are:
>  
>    off		Disables hypervisor mitigations and doesn't emit any
>  		warnings.
> +		It also drops the swap size and available RAM limit restrictions
> +		on both hypervisor and bare metal.
> +
>    ============  =============================================================
>  
>  The default is 'flush'. For details about L1D flushing see :ref:`l1d_flush`.
> @@ -576,7 +582,8 @@ Default mitigations
>    The kernel default mitigations for vulnerable processors are:
>  
>    - PTE inversion to protect against malicious user space. This is done
> -    unconditionally and cannot be controlled.
> +    unconditionally and cannot be controlled. The swap storage is limited
> +    to ~16TB.
>  
>    - L1D conditional flushing on VMENTER when EPT is enabled for
>      a guest.
> 
> 
> 
> 



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [patch] Fix up l1ft documentation was Re: Taking a break - time to look back

[Thomas Gleixner]

On Mon, 11 Mar 2019, Pavel Machek wrote:
> On Thu 2019-01-03 00:51:52, Pavel Machek wrote:
> > Hi!
> > 
> > > The next round of speculation-related issues including the scary L1TF
> > > hardware bug was a way more "pleasant" experience to work on. While for
> > > obvious reasons the mitigation development happened behind closed doors in
> > > a smaller group of people, we were at least able to collaborate in a way
> > > which is somehow close to what we are used to.
> > 
> > Ok, I guess L1TF was a lot of fun, and there was not time for a good
> > documentation.
> > 
> > There's admin guide that is written as an advertisment, and

What's advertisement there?

> > unfortunately is slightly "inaccurate" at places (to the point of
> > lying).

Huch? Care to tell what's a lie instead of making bold statements?

Thanks,

	tglx

Re: [patch] Fix up l1ft documentation was Re: Taking a break - time to look back

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 4263 bytes --]

On Mon 2019-03-11 14:05:07, Thomas Gleixner wrote:
> On Mon, 11 Mar 2019, Pavel Machek wrote:
> > On Thu 2019-01-03 00:51:52, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > The next round of speculation-related issues including the scary L1TF
> > > > hardware bug was a way more "pleasant" experience to work on. While for
> > > > obvious reasons the mitigation development happened behind closed doors in
> > > > a smaller group of people, we were at least able to collaborate in a way
> > > > which is somehow close to what we are used to.
> > > 
> > > Ok, I guess L1TF was a lot of fun, and there was not time for a good
> > > documentation.
> > > 
> > > There's admin guide that is written as an advertisment, and
> 
> What's advertisement there?

"No problem here, no performance issues, nothing to be seen unless you
are running VM."

> > > unfortunately is slightly "inaccurate" at places (to the point of
> > > lying).
> 
> Huch? Care to tell what's a lie instead of making bold statements?

Take a care to look at the patch I submitted?

Lie:

# A system with an up to date kernel is protected against attacks from
# malicious user space applications.

3GB system running 32bit kernel is not protected. Same is true for for
really big 64bit systems.

If I do what dmesg suggests, this becomes untrue:

# The Linux kernel contains a mitigation for this attack vector, PTE
# inversion, which is permanently enabled and has no performance
# impact.

Limiting memory to 2GB _is_ going to have severe perfomance impact.

								Pavel

commit 9664b4dabdb132433a6843aefe05814953f1342f
Author: Pavel <pavel@ucw.cz>
Date:   Thu Jan 3 00:48:40 2019 +0100

    Ok, I guess L1TF was a lot of fun, and there was not time for a good
    documentation.
    
    There's admin guide that is written as an advertisment, and
    unfortunately is slightly "inaccurate" at places (to the point of
    lying).
    
    Plus, I believe it should go to x86/ directory, as this is really
    Intel issue, and not anything ARM (or RISC-V) people need to know.
    
    Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/Documentation/admin-guide/l1tf.rst b/Documentation/admin-guide/l1tf.rst
index 9af9773..05c5422 100644
--- a/Documentation/admin-guide/l1tf.rst
+++ b/Documentation/admin-guide/l1tf.rst
@@ -1,10 +1,11 @@
 L1TF - L1 Terminal Fault
 ========================
 
-L1 Terminal Fault is a hardware vulnerability which allows unprivileged
-speculative access to data which is available in the Level 1 Data Cache
-when the page table entry controlling the virtual address, which is used
-for the access, has the Present bit cleared or other reserved bits set.
+L1 Terminal Fault is a hardware vulnerability on most recent Intel x86
+CPUs which allows unprivileged speculative access to data which is
+available in the Level 1 Data Cache when the page table entry
+controlling the virtual address, which is used for the access, has the
+Present bit cleared or other reserved bits set.
 
 Affected processors
 -------------------
@@ -76,12 +77,14 @@ Attack scenarios
    deterministic and more practical.
 
    The Linux kernel contains a mitigation for this attack vector, PTE
-   inversion, which is permanently enabled and has no performance
-   impact. The kernel ensures that the address bits of PTEs, which are not
-   marked present, never point to cacheable physical memory space.
-
-   A system with an up to date kernel is protected against attacks from
-   malicious user space applications.
+   inversion, which is permanently enabled and has no measurable
+   performance impact in most configurations. The kernel ensures that
+   the address bits of PTEs, which are not marked present, never point
+   to cacheable physical memory space. On x86-32, this physical memory
+   needs to be limited to 2GiB to make mitigation effective.
+
+   Mitigation is present in kernels v4.19 and newer, and in
+   recent -stable kernels.
 
 2. Malicious guest in a virtual machine
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [patch] Fix up l1ft documentation was Re: Taking a break - time to look back

[Jonathan Corbet]

On Mon, 11 Mar 2019 11:21:10 +0100
Pavel Machek <pavel@ucw.cz> wrote:

> Ping? Jonathan, can you pick this up?

I would really like to get an ack from the people who have been deep into
this first.  If you can get that, and preferably resubmit with a less
condescending changelog, I can pick it up.

Thanks,

jon

Re: [patch] Fix up l1ft documentation was Re: Taking a break - time to look back

[Thomas Gleixner]

Pavel,

On Mon, 11 Mar 2019, Pavel Machek wrote:
> On Mon 2019-03-11 14:05:07, Thomas Gleixner wrote:
> > Huch? Care to tell what's a lie instead of making bold statements?
> 
> Take a care to look at the patch I submitted?
> 
> Lie:
> 
> # A system with an up to date kernel is protected against attacks from
> # malicious user space applications.
> 
> 3GB system running 32bit kernel is not protected. Same is true for for
> really big 64bit systems.

I agree that this statement is incorrect.

Calling this a lie is a completly unjustified personal attack on those who
spent quite a lot of time on writing up documentation in the first
place. It's suggesting that this document was written with malicious intent
and the purpose of deceiving someone. Care to explain why you are assuming
this to be the case?

> If I do what dmesg suggests, this becomes untrue:
> 
> # The Linux kernel contains a mitigation for this attack vector, PTE
> # inversion, which is permanently enabled and has no performance
> # impact.
> 
> Limiting memory to 2GB _is_ going to have severe perfomance impact.

Sure. That still does not justify the "changelog" you provided.

> commit 9664b4dabdb132433a6843aefe05814953f1342f
> Author: Pavel <pavel@ucw.cz>
> Date:   Thu Jan 3 00:48:40 2019 +0100
> 
>     Ok, I guess L1TF was a lot of fun, and there was not time for a good
>     documentation.

It's interesting that quite some people were actually happy about that
document. Sorry, that we weren't able to live up to your high standards.

>     There's admin guide that is written as an advertisment, and

What is the advertisement part again?

>     unfortunately is slightly "inaccurate" at places (to the point of
>     lying).
>     
>     Plus, I believe it should go to x86/ directory, as this is really
>     Intel issue, and not anything ARM (or RISC-V) people need to know.

It's a document targeted at system administrators and it definitely should
not be burried somewhere in Documentation/x86. As there are more documents
being worked on for the other issues, I have a patch ready which moves that
stuff into a separate hardware vulnerabilites folder in the admin-guide.

FWIW, to the best of my knowledge the documentation about writing
changelogs is neither incorrect nor is it optional to adhere to it.

> @@ -1,10 +1,11 @@
>  L1TF - L1 Terminal Fault
>  ========================
>  
> -L1 Terminal Fault is a hardware vulnerability which allows unprivileged
> -speculative access to data which is available in the Level 1 Data Cache
> -when the page table entry controlling the virtual address, which is used
> -for the access, has the Present bit cleared or other reserved bits set.
> +L1 Terminal Fault is a hardware vulnerability on most recent Intel x86

The 'Affected processors' section right below this is very clear about this
being an Intel only issue (for now). So what exactly is the point of this
change?

> +CPUs which allows unprivileged speculative access to data which is
> +available in the Level 1 Data Cache when the page table entry
> +controlling the virtual address, which is used for the access, has the
> +Present bit cleared or other reserved bits set.
>  
>  Affected processors
>  -------------------
> @@ -76,12 +77,14 @@ Attack scenarios
>     deterministic and more practical.
>  
>     The Linux kernel contains a mitigation for this attack vector, PTE
> -   inversion, which is permanently enabled and has no performance
> -   impact. The kernel ensures that the address bits of PTEs, which are not
> -   marked present, never point to cacheable physical memory space.
> -
> -   A system with an up to date kernel is protected against attacks from
> -   malicious user space applications.
> +   inversion, which is permanently enabled and has no measurable
> +   performance impact in most configurations. The kernel ensures that
> +   the address bits of PTEs, which are not marked present, never point
> +   to cacheable physical memory space. On x86-32, this physical memory

On x86-32? That's incorrect, because there are a lot of x86-32 systems
which are not affected. Also it has nothing to do with the bit-width of the
hardware. A 32bit kernel booted on a 64bit capable CPU has the same issue.
For further correctness, this needs to mention that !PAE enabled kernels
cannot do PTE inversion at all.

> +   needs to be limited to 2GiB to make mitigation effective.

The 2G limitation is not a general limitation. The limitation depends on
the number of physical address bits supported by the cache (not the number
of physical addresss bits exposed as pins) and is definitely not hardcoded
to 2G. Just because your machine emits the 2G number does not make it
universally correct. On a system with 36bit physical address space the
limit is 32G and on some CPUs that's actually wrong as well, see:
override_cache_bits().

Quoting yourself:

> 3GB system running 32bit kernel is not protected. Same is true for for
> really big 64bit systems.

Where is the explanation for the 'really big 64bit systems' issue for
correctness sake?

Thanks,

	tglx

Re: [patch] Fix up l1ft documentation was Re: Taking a break - time to look back

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 4917 bytes --]

On Mon 2019-03-11 23:31:08, Thomas Gleixner wrote:
> Pavel,
> 
> On Mon, 11 Mar 2019, Pavel Machek wrote:
> > On Mon 2019-03-11 14:05:07, Thomas Gleixner wrote:
> > > Huch? Care to tell what's a lie instead of making bold statements?
> > 
> > Take a care to look at the patch I submitted?
> > 
> > Lie:
> > 
> > # A system with an up to date kernel is protected against attacks from
> > # malicious user space applications.
> > 
> > 3GB system running 32bit kernel is not protected. Same is true for for
> > really big 64bit systems.
> 
> I agree that this statement is incorrect.
> 
> Calling this a lie is a completly unjustified personal attack on those who

So how should it be called? I initally used less strong words, only to
get "Care to tell what's a lie instead of making bold statements?"
back. Also look at the timing of the thread.

> >     Ok, I guess L1TF was a lot of fun, and there was not time for a good
> >     documentation.
> 
> It's interesting that quite some people were actually happy about that
> document. Sorry, that we weren't able to live up to your high
> standards.

Ok, now can we have that document updated to meet the standards?

> > @@ -1,10 +1,11 @@
> >  L1TF - L1 Terminal Fault
> >  ========================
> >  
> > -L1 Terminal Fault is a hardware vulnerability which allows unprivileged
> > -speculative access to data which is available in the Level 1 Data Cache
> > -when the page table entry controlling the virtual address, which is used
> > -for the access, has the Present bit cleared or other reserved bits set.
> > +L1 Terminal Fault is a hardware vulnerability on most recent Intel x86
> 
> The 'Affected processors' section right below this is very clear about this
> being an Intel only issue (for now). So what exactly is the point of this
> change?

Making it very clear from the begining this is x86-only issue. Yes,
you can kind-of figure it out from the next section... except for
Intel StrongArm.

Next sentence speaks about "present bit" of "page table entry". That
may be confusing for people familiar with other architectures, which
may not have such bit. We should mention this is x86 before using
x86-specific terminology.

> hardware. A 32bit kernel booted on a 64bit capable CPU has the same issue.
> For further correctness, this needs to mention that !PAE enabled kernels
> cannot do PTE inversion at all.

Ok.

> > 3GB system running 32bit kernel is not protected. Same is true for for
> > really big 64bit systems.
> 
> Where is the explanation for the 'really big 64bit systems' issue for
> correctness sake?

I don't know the detailed limits for each system; what about this?

Signed-off-by: Pavel Machek <pavel@ucw.cz>

									Pavel

diff --git a/Documentation/admin-guide/l1tf.rst b/Documentation/admin-guide/l1tf.rst
index 9af9773..cbf02a4 100644
--- a/Documentation/admin-guide/l1tf.rst
+++ b/Documentation/admin-guide/l1tf.rst
@@ -1,10 +1,11 @@
 L1TF - L1 Terminal Fault
 ========================
 
-L1 Terminal Fault is a hardware vulnerability which allows unprivileged
-speculative access to data which is available in the Level 1 Data Cache
-when the page table entry controlling the virtual address, which is used
-for the access, has the Present bit cleared or other reserved bits set.
+L1 Terminal Fault is a hardware vulnerability on most recent Intel x86
+CPUs which allows unprivileged speculative access to data which is
+available in the Level 1 Data Cache when the page table entry
+controlling the virtual address, which is used for the access, has the
+Present bit cleared or other reserved bits set.
 
 Affected processors
 -------------------
@@ -76,12 +77,15 @@ Attack scenarios
    deterministic and more practical.
 
    The Linux kernel contains a mitigation for this attack vector, PTE
-   inversion, which is permanently enabled and has no performance
-   impact. The kernel ensures that the address bits of PTEs, which are not
-   marked present, never point to cacheable physical memory space.
-
-   A system with an up to date kernel is protected against attacks from
-   malicious user space applications.
+   inversion, which has no measurable performance impact in most
+   configurations. The kernel ensures that the address bits of PTEs,
+   which are not marked present, never point to cacheable physical
+   memory space. For mitigation to be effective, physical memory needs
+   to be limited in some configurations.
+
+   Mitigation is present in kernels v4.19 and newer, and in
+   recent -stable kernels. PAE needs to be enabled for mitigation to
+   work.
 
 2. Malicious guest in a virtual machine
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [patch] Fix up l1ft documentation was Re: Taking a break - time to look back

[Thomas Gleixner]

Pavel,

On Tue, 12 Mar 2019, Pavel Machek wrote:
> On Mon 2019-03-11 23:31:08, Thomas Gleixner wrote:
> > Calling this a lie is a completly unjustified personal attack on those who
> 
> So how should it be called? I initally used less strong words, only to
> get "Care to tell what's a lie instead of making bold statements?"
> back. Also look at the timing of the thread.

You called it a lie from the very beginning or what do you think made me
tell you that? Here is what you said:

> There's admin guide that is written as an advertisment, and
> unfortunately is slightly "inaccurate" at places (to the point of
> lying).

Nice try.

> > >     Ok, I guess L1TF was a lot of fun, and there was not time for a good
> > >     documentation.
> > 
> > It's interesting that quite some people were actually happy about that
> > document. Sorry, that we weren't able to live up to your high
> > standards.
> 
> Ok, now can we have that document updated to meet the standards?

What is 'the standards'? Your's or is there a general agreement?

> > > -L1 Terminal Fault is a hardware vulnerability which allows unprivileged
> > > -speculative access to data which is available in the Level 1 Data Cache
> > > -when the page table entry controlling the virtual address, which is used
> > > -for the access, has the Present bit cleared or other reserved bits set.
> > > +L1 Terminal Fault is a hardware vulnerability on most recent Intel x86
> > 
> > The 'Affected processors' section right below this is very clear about this
> > being an Intel only issue (for now). So what exactly is the point of this
> > change?
> 
> Making it very clear from the begining this is x86-only issue. Yes,
> you can kind-of figure it out from the next section... except for
> Intel StrongArm.

It's pretty clear, but yes admittedly we forgot to mention that Intel
StrongARM is not affected. That's truly important because its widely
deployed in the cloud space and elsewhere.

> Next sentence speaks about "present bit" of "page table entry". That
> may be confusing for people familiar with other architectures, which
> may not have such bit. We should mention this is x86 before using
> x86-specific terminology.

X86 terminology? Care to check how pte_present() is implemented across the
architectures? Most of them use the PRESENT bit naming convention, just a
few use VALID. That's truly confusing and truly x86 specific.

> > > 3GB system running 32bit kernel is not protected. Same is true for for
> > > really big 64bit systems.
> > 
> > Where is the explanation for the 'really big 64bit systems' issue for
> > correctness sake?
> 
> I don't know the detailed limits for each system; what about this?

It's not about detailed limits for particular systems. It's about the way
the limit is determined on certain class of systems. And that can be
deduced from the code.

If you want to provide more accurate documentation then you better come up
with something which is helpful instead of completely useless blurb like
the below:

> -   malicious user space applications.
> +   inversion, which has no measurable performance impact in most
> +   configurations. The kernel ensures that the address bits of PTEs,
> +   which are not marked present, never point to cacheable physical
> +   memory space. For mitigation to be effective, physical memory needs
> +   to be limited in some configurations.

How is the admin going to figure that out? What kind of systems might be
affected by this?

> +   Mitigation is present in kernels v4.19 and newer, and in
> +   recent -stable kernels. PAE needs to be enabled for mitigation to
> +   work.

No. The mitigation is available when the kernel provides it. Numbers are
irrelevant because that documentation has to be applicable for stable
kernels as well. And what is a recent -stable kernel?

Also the PAE part needs to go to a completely different section.

Thanks,

	tglx

Re: [patch] Fix up l1ft documentation was Re: Taking a break - time to look back

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

Hi!

> On Tue, 12 Mar 2019, Pavel Machek wrote:
> > On Mon 2019-03-11 23:31:08, Thomas Gleixner wrote:
> > > Calling this a lie is a completly unjustified personal attack on those who
> > 
> > So how should it be called? I initally used less strong words, only to
> > get "Care to tell what's a lie instead of making bold statements?"
> > back. Also look at the timing of the thread.
> 
> You called it a lie from the very beginning or what do you think made me
> tell you that? Here is what you said:

Actually, I still call it a lie. Document clearly says that bug is
fixed in non-virtualized cases, when in fact it depends on PAE and
limited memory.

> If you want to provide more accurate documentation then you better come up
> with something which is helpful instead of completely useless blurb like
> the below:

At this point I want you to fix it yourself. Lying about security bugs
being fixed when they are not is not cool. I tried to be helpful and
submit a patch, but I don't feel like you are cooperating on getting
the patch applied.

> > +   Mitigation is present in kernels v4.19 and newer, and in
> > +   recent -stable kernels. PAE needs to be enabled for mitigation to
> > +   work.
> 
> No. The mitigation is available when the kernel provides it. Numbers are
> irrelevant because that documentation has to be applicable for stable
> kernels as well. And what is a recent -stable kernel?
> 
> Also the PAE part needs to go to a completely different section.

Best regards,
								Pavel


-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]