I'm confused about the TLB impact. The pythonsweetness link claims these patches now require TLB flushes when crossing the kernel/user boundary, but the description of KAISER @ lwn[1] suggests that these flushes are unnecessary with "more recent" processors supporting PCIDs. How recent is "more recent", and is the PCID support likely to be ported back to earlier kernels along with KPTI?
TLB flushes for syscalls would be absolutely brutal for many performance-critical applications.
If the problem is row-hammer style attacks on the TLB that let you map userspace writable pages into the kernel address space then any kernel entries remaining in the TLB when userspace is running are going to be a security hole. The problem won’t be a process writing to the kernel entry (that would be forbidden by existing code / hardware) but a process updating it’s own TLB entries in ways that corrupt adjacent kernel ones. PCID doesn't help you here - indeed it hurts, because it means there are more TLB entries from the hypervisor or other virtual machines remaining in the TLB to be corrupted!
(Unless I have entirely the wrong end of the stick about this?)
I took OP to mean "rowhammer style" in the sense of a chip operation having unexpected physical effects on nearby transistors; not an attack literally identical to rowhammer.
No, the attack is simply a timing side-channel infoleak attack made possible by the TLB speeding up page fault handling to locate kernel structures mapped into the process' address space.
As far as I know PCID hidden entries in the TLB result in the same page fault as non-existent entries, so the page fault handling becomes constant timed.
I dunno, it sounds like it might be easiest to go ahead and backport PCID along with these patches. It touches a lot of the same code, so trying to split it out might just create more problems.
Yes, and the impact on syscall-intensive workloads is bad enough with PCID, without it it's even worse. I'd be moderately surprised if only KPTI is backported and not PCID.
TLB flushes for syscalls would be absolutely brutal for many performance-critical applications.
[1] https://lwn.net/Articles/738975/