OK, finally an actually-working Spectre v1 mitigation: mov %cr0,%eax or $0x40000000,%eax mov %eax,%cr0 wbinvd
Oh wait. If the cpu has HT, can you just steal a whole HT thread to constantly clobber BTBs?
-
-
This should be easy to test without kernel hacks. Pin task to odd-numbered core, set max realtime priority, spam insns that clobber btbs, run spectre test.
-
I'd love to hear the outcome of such a test.
End of conversation
New conversation -
-
-
ugh. How about just putting *secret* data into the uncached/device memory? And not care about the non-secret?
-
It doesn't scale. Requires hacks in every application that might have secrets. It's like foregoing MMU: instead of a general-purpose safety mechanism you have to manually ensure every check is right.
-
If you unmap userspace memory upon kernel entry (aka Meltdown) fix and remove physmap from kernel, you shall be able to mitigate cross-app leakage. Am I right?
-
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 -
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.