Pavel,

On Tue, 12 Mar 2019, Pavel Machek wrote:

On Mon 2019-03-11 23:31:08, Thomas Gleixner wrote:

quoted

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.

quoted

quoted

    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?

quoted

quoted

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

quoted

quoted

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