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

[GrayShade]

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

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.