linux-kernel - Re: [patch] Fix up l1ft documentation was Re: Taking a break

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 24 Mar 2019 21:41:20 +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 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