Message-ID: <20190312115757.GA29955@amd>
Date:   Tue, 12 Mar 2019 12:57:57 +0100
From:   Pavel Machek <pavel@....cz>
To:     Thomas Gleixner <tglx@...utronix.de>
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

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

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists