4 ms·
I think the idea is that faults on sensitive pages are known to be good, because they can only come when running kernel code. They are unmapped when exiting fro
by e63f67dd-065b 4y ago
I think the idea is that faults on sensitive pages are known to be good, because they can only come when running kernel code. They are unmapped when exiting from kernel code, so in theory there's no way for userspace to speculatively execute on those pages and leak sensitive memory.
It does seem to be a good fix for the root cause of the problem, but I'm skeptical about the details. I haven't look through the patch set, but narrowing down what's sensitive and what isn't is going to be a monumental task.
- deleted 4y ago[deleted]
- pas 4y agounmapped pages cannot be speculatively executed "into"? (due to TLB flush? which happens during unmapping?)
- simcop2387 4y agoMy understanding is that this is because the tlb update can't be speculated through. That means that once speculative execution hits that barrier it will stop and can't then look at data that would be mapped in if speculation kept going. Basically there's a hard fence there that it won't/can't go past so if you do hit a page fault in kernel space on one of the unmapped pages you know it will be from an active and not speculative thread running.