3 ms·

I thought that: mov rax, [Somekerneladdress] would trigger an interrupt even on speculative execution as described on https://cyber.wtf/2017/07/28/negative-re

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-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 ago
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 9y ago
  So it is a game over here. Unless Intel can change the microcode to force a page fault in this case.
  - bstx 9y ago
    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 9y ago
      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 9y ago
        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 9y ago
Concretely, 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.

dmitrygr 9y ago

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 9y ago
So it is a game over here. Unless Intel can change the microcode to force a page fault in this case.
- bstx 9y ago
  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 9y ago
    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 9y ago
      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 9y ago

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