is that the “disable branch prediction altogether” flag that you said existed and I claimed might revert the processor to static prediction instead?
No. The idea of Spectre v1 is that you trick a process to leak parts of its own memory via cache side channels. Malicious code in JIT is the obvious/easy way but far from the only one.
-
-
I suspect it's even possible to make a jpeg or png whose decoding time (thus time between network requests) leaks auth tokens out of the browser.
-
Ah I see, you are talking about v1 and I was thinking mostly about v2. I'll take a pause to think more about it
-
Yes. Spectre v2 mitigation is a solved problem except for making it less costly. Spectre v1 has no solution so far except using unaffected hardware or the above "4-5 nines" jokes.
End of conversation
New conversation -
-
-
Ok, but why would you want to flush the branch predictor cache all the time and not upon exiting from the exception?
-
So that one code path in the victim process can't be coerced into leaking unrelated parts of the process's own memory. That's what Spectre v1 is.
-
The only mitigation without new Si is to turn off speculative execution across branches, and cpu vendors won't give us an MSR for that (because perf hit looks bad on them), so forcibly prevent branch prediction instead using HT.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.