4 ms·
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
by pja 9y ago
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?)
- kijiki 9y agoI don't think rowhammer style attacks are possible on TLBs, since they are SRAMs (CAMs, to be precise), not DRAMs.
- sbierwagen 9y agoI 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.
- pja 9y agoYes, that was my intention. Probably could have been clearer.
- dboreham 9y agoSRAMs can have pattern sensitivity too.
- pas 9y agoNo, 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.