Talk:Kernel page-table isolation

CVE-2017-5925 and CVE-2017-5926

These don't seem to be the issues requiring KPTI for mitigation. I deleted the reference to them since I couldn't find a source confirming a link between theses CVEs and KPTI. — Preceding unsigned comment added by Phiarc (talk • contribs)

@Phiarc: Thanks, you're right. These CVEs were mentioned in [this LKML post https://lkml.org/lkml/2017/11/23/175] in the KAISER thread, but re-reading it now, clearly the CVEs are about a different issue. -- intgr [talk] 13:33, 2 January 2018 (UTC)

Notability

The specific linux patch in question is not notable and no notability can be established. As per WP:INHERITORG the patch does not automatically become notable because the bug is notable which is an entirely different subject matter. Someone please open an AfD for this article. --64.121.146.209 (talk) 01:44, 5 January 2018 (UTC)

WP:INHERITORG does not apply. KPTI is, of course, notable per WP:NOTABILITY. There's broad (and also deep) media coverage. --Matthiaspaul (talk) 03:37, 5 January 2018 (UTC)

Coverage of the patch is almost non-existent in the media, coverage of the bug is. Secondly, go check the list of references they are all primary sources (either the papers, LWN.net, or kernel.org). You can't use them to claim notability. Thirdly, there is only a single mainstream article (despite your claims of "broad media coverage") and it's this techcrunch article https://techcrunch.com/2018/01/03/kernel-panic-what-are-meltdown-and-spectre-the-bugs-affecting-nearly-every-computer-and-device/ and there is only a single sentence about the kernel patch in there under the "Can this be fixed" section. So no, that doesn't constitute notability. --64.121.146.209 (talk) 06:14, 5 January 2018 (UTC)

LWN.net is not a primary source. It's a news publication summarizing primary sources (including kernel mailing list discussions, patches, research papers, etc), so pretty much the definition of a secondary source. I also added some new citations to the article; [1] and [2] primarily discuss Linux and KPTI/KAISER. This The Register article [3] also has a section with many paragraphs about Linux and KPTI. I consider WP:GNG satisfied by LWN coverage and these links.

PS: Be careful making claims without evidence. If you want to claim that "no notability can be established" then it implies you've already tried looking for sources and failed (and even then you cannot prove a negative).

You can say something like "notability is not established given the sources currently in the article" or "I couldn't find sufficient new sources to establish notability". Otherwise you'll just look like an idiot. -- intgr [talk] 09:17, 5 January 2018 (UTC)

Please explain how a bug (Meltdown) can be more notable than a previously-known solution (KAISER/KTPI) that solves a broader class of bugs. Quite obviously this broader solution, while not specifically aware of Meltdown, is built with knowledge of something bigger than Meltdown. — Preceding unsigned comment added by 108.185.180.195 (talk) 19:00, 5 January 2018 (UTC)

@108.185.180.195: Regarding your comment and edits to the article: You cannot simply claim or imply that KAISER was "built with knowledge of something bigger than Meltdown" without good evidence. Linux and other OSes had used the optimization trick of leaving kernel memory mapped while executing user space code, long before out-of-order CPUs were a thing. Newer CPU generations introduced optimizations of their own that turned out to be unsafe. KAISER merely disabled this OS optimization. It's a fairly obvious workaround, but a step backwards in OS design, not some great insight. -- intgr [talk] 19:20, 5 January 2018 (UTC)

This whole article is misleading

Kernal page tables are part of every application. It's access is restricted by mode. The problem here is the translation look aside buffer will fetch data which may or may not be used. It's speculative so it happens during a user process and left there if the CPU doesn't take the branch. Out-of-order, multi-core, virtual cores and speculative execution increases the risk. If the solution is to flush the TLB so the kernel entries are marked invalid, it incurs a penalty for every misprediction or context switch. KPTI is not limited to this security hole, rather it's a hardware architecture problem and is addressed as a security issue. There will likely be an additional KPTI page table added in future CPUs. x86 controls the pagetable in hardware so isolating the kernel memory from user memory will need a physically new kernel page table. x86 already has multiple page tables for each level of cache. Software just forces a flush every time there is a context switch likely by forcing a miss. This article need to be a bigger scope article on what KPTI is and not just Intel's errata. --DHeyward (talk) 08:44, 5 January 2018 (UTC)

The security issue itself is covered in the Meltdown (security vulnerability) article. KPTI is just a feature in Linux to mitigate Meltdown. -- intgr [talk] 09:22, 5 January 2018 (UTC)

No sorry, that's wrong. KPTI/KAISER patch also covers other processors such as ARM which are not affected by Meltdown - https://patchwork.kernel.org/patch/10064879/ --64.121.146.209 (talk) 11:21, 5 January 2018 (UTC)

Please be clearer, what exactly is wrong? If you're talking about KPTI fixing KASLR bypass, then that was explained in the "Background on KAISER" section. I realize that was missing in the lead and added it there too. Does this address your concern?

Interestingly, in the Patchwork thread you linked, they claim that KPTI improves KASLR defenses on ARM, but that is contradicted by the original KAISER paper: "On ARM architectures, the user and kernel addresses are already distinguished based on registers, and thus no cache access and no timing difference occurs"

"Similar translation tables exist on modern ARM (Cortex-A) processors too, with small differences in size and property bits. One significant difference to x86-64 is that ARM CPUs have two registers to store physical addresses of translation tables (TTBR0 and TTBR1). Typically, one is used to map the user address space (lower half) whereas the other is used to map the kernel address space (upper half). Gruss et al. [6] speculated that this might be one of the reasons why the attack does not work on ARM processors."

Are there any sources to confirm ARM's vulnerability to KASLR bypass in the first place (other than Cortex A75)?

As for ARM being unaffected by Meltdown: ARM's response states that Cortex A75 cores are vulnerable to "Variant 3" of the attack and that will be mitigated with KPTI. The original Project Zero blog article classifies the variants as as "Spectre (variants 1 and 2)" and "Meltdown (variant 3)". I would conclude that A75 is in fact vulnerable to the Meltdown as are Intel's CPUs. But it's difficult to state that in Wikipedia since the sources aren't precise enough (that I've seen) and doing so might be original research. -- intgr [talk] 16:10, 5 January 2018 (UTC)

Okay, I found a source that clearly states the Cortex A75 situation and updated the article. I also changed the claim "the Meltdown vulnerability [...] affecting only Intel x86 processors", which indeed was misleading. Anything else? -- intgr [talk] 16:49, 5 January 2018 (UTC)

Help clarify this as all the articles are approaching this as software. Meltdown, for example describes the vulnerability and patches to "fix" it. But the concept of "Kernel Page Table Isolation," at least in language is an architectural description of a processor architecture. When the CPU is architected to implement stricter Kernel Page Table Isolation through the use of new TLBs and page tables reserved for the kernel. These exploits, i.e. Meltdown, are faults in the the current "Kernel Page Table Isolation" hardware implementation. Am I missing something? --DHeyward (talk) 22:08, 5 January 2018 (UTC)

Performance

Maybe also add tests like https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests which confirm negligible overheads for gaming as a real-world use case. — Preceding unsigned comment added by Dgruss (talk • contribs)

Note that the citation is already there, but hasn't been summarized. -- intgr [talk] 12:39, 8 January 2018 (UTC)