Message-ID: <alpine.DEB.2.21.1903112211180.1651@nanos.tec.linutronix.de>
Date:   Mon, 11 Mar 2019 23:31:08 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Pavel Machek <pavel@....cz>
cc:     corbet@....net, LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Jiri Kosina <jkosina@...e.cz>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Joerg Roedel <joro@...tes.org>,
        Tony Luck <tony.luck@...el.com>,
        Salvatore Bonaccorso <carnil@...ian.org>,
        linux-doc@...r.kernel.org
Subject: Re: [patch] Fix up l1ft documentation was Re: Taking a break - time
 to look back

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

Powered by blists - more mailing lists