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