More details about mitigations for the CPU Speculative Execution issue

Re:More details about mitigations for the CPU Speculative Ex... by dmitrygr on Thursday January 04, 2018 @04:55PM (#16074435)

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

[ Parent | on HN ]

Re:More details about mitigations for the CPU Speculative Ex... by j_coder on Thursday January 04, 2018 @05:15PM (#16074591)

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

[ Parent | on HN ]

Re:More details about mitigations for the CPU Speculative Ex... by bstx on Thursday January 04, 2018 @07:46PM (#16075530)

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

[ Parent | on HN ]

Re:More details about mitigations for the CPU Speculative Ex... by j_coder on Thursday January 04, 2018 @08:43PM (#16075815)

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.

[ Parent | on HN ]

Re:More details about mitigations for the CPU Speculative Ex... by GrayShade on Friday January 05, 2018 @02:05AM (#16077085)

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.

[ Parent | on HN ]