As expected, silence on Spectre v1. But nice job @arstechnica being explicit that the microcode fixes are for Spectre v2.https://twitter.com/DrPizza/status/966389985510416385 …
-
-
Replying to @RichFelker @arstechnica
I think v1 is going to pretty universally require application-level fixes.
1 reply 0 retweets 0 likes -
Replying to @DrPizza @arstechnica
An MSR to disable branch predictor should suffice. Need lawyers forcing Intel to do it (and fix the bug in future cpus).
2 replies 0 retweets 0 likes -
Replying to @RichFelker @arstechnica
So you want to end all speculation past a cmp?
2 replies 0 retweets 0 likes -
Spectre v1 doesn't cross protection domains, and we want correct speculations to be able to cause cache misses.
1 reply 0 retweets 0 likes -
Replying to @DrPizza @arstechnica
Rich Felker Retweeted Rich Felker
Rich Felker added,
1 reply 0 retweets 0 likes -
Replying to @RichFelker @arstechnica
No it doesn't. The only architectural protection domains are the rings, to an extent different values of CR3, and SGX.
3 replies 0 retweets 0 likes -
Software-enforced domains (sandboxes, etc.) need software-enforced fixes.
1 reply 0 retweets 0 likes -
Replying to @DrPizza @arstechnica
The scope of Spectre v1 is way bigger than things you actively think of as "sandboxes". It's unbounded attack surface. There will be clever new exploits of this for *decades* if the underlying bug is not fixed.
2 replies 0 retweets 0 likes -
So no, I don't want correct speculations to cause cache misses. Preventing that would cost <1% perf to workloads with low to moderate cache miss rate. But I don't believe it's possible with just uc updates, needs bigger changes.
2 replies 0 retweets 0 likes
On the other hand, just turning off branch prediction should be possible with an MSR; early x86's with branch prediction actually had an MSR documented to do just that.
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.