7 ms·
I suspect a better solution instead of KPTI is to evict all user space pages from cache when an invalid page access happens if fault was caused by read/write ke
by j_coder 9y ago
I suspect a better solution instead of KPTI is to evict all user space pages from cache when an invalid page access happens if fault was caused by read/write kernel space pages. My kernel days was so long ago that I don't now if it is possible.
Massive performance hit but only on misbehaved software. Well behaved software will not have the performance hit of KPTI.
Kernel could even switch dynamically to KPTI if too many read/write attempts from user space.
- corsix 9y agoImplementations of meltdown do not need to trigger a page fault (because the instruction which would fault can be made to execute speculatively - in addition to the instruction which leaks information into the cache executing speculatively). Accordingly, there would be nothing for the kernel to observe or respond to.
- j_coder 9y agoI thought that: mov rax, [Somekerneladdress] would trigger an interrupt even on speculative execution as described on https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ https://cyber.wtf/2017/07/28/negative-result-reading-kernel-... ADDED: So in the interrupt handler the kernel could evict all user space pages from cache before returning control to user space so it could not use the timing attack on the cache of the speculative execution of Mov rbx,[rax+Someusermodeaddress] on the address rax+Someusermodeaddress.
- dmitrygr 9y agoand what if it was preceded with cmp $0, [some_readable_but_uncached_addr_containing_zero] je some_safe_location //now the exploit mov rax, [somekerneladdr] ...the rest of it... cpu may speculatively execute past "jz" and speculatively do the load. no fault generated
- j_coder 9y agoSo it is a game over here. Unless Intel can change the microcode to force a page fault in this case.
- bstx 9y agoIt doesn't make sense for speculatively executed code to throw architecturally visible exceptions. The appropriate behavior would be to not perform speculative loads across protection domains (i.e. the behavior of AMD implementations).
- j_coder 9y agoIt would make sense if it was the only alternative as the kernel can handle it. The appropriate behavior is to remove all traces of the speculative execution including cache hits.
- GrayShade 9y agoIs that even possible? The data that would need to be removed from the cache has already evicted other cache lines, and that re-fetching those might have observable effects, like the timing.
- corsix 9y agoConcretely, https://twitter.com/corsix/status/948670437432659970 https://twitter.com/corsix/status/948670437432659970 can be used to get both `movzx rax, byte [somekerneladdress]` and `movzx rax, byte [rax+someusermodeaddress]` executed speculatively (the idea behind this is the same as a retpoline - exploit the fact that `ret` is predicted to return to just after the "matching" `call` instruction). If the first load is executed speculatively, it won't cause a page fault.
- gpm 9y agoEven if a fault occurred (others are correct in pointing out it doesn't necessarily) I think this would be too late. I could have already observed the effects in the cache before the instruction causing was (non speculatively) reached and the fault occurred.
- mtgx 9y agoThat sounds like the kind of proposal for which Linus would scream at you.
- j_coder 9y agoI would never send to him :)