[j_coder]

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]

Implementations 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]

I 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-...

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]

and 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]

So it is a game over here. Unless Intel can change the microcode to force a page fault in this case.

[bstx]

It 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]

It 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.

[corsix]

Concretely, 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]

Even 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]

That sounds like the kind of proposal for which Linus would scream at you.

[j_coder]

I would never send to him :)