Spectre/Meltdown nominated for most over hyped bug at Pwnies
pic.twitter.com/TVJ8OXXFRy
You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
I believe it's plausible to design a CPU that speculates without visible side effects, but it sounds difficult. I don't believe it's possible to add that via microcode. An MSR to disable all speculation should be possible as a microcode update.
and I believe even that approach needs microcode update; over CPU vendors are proposing other mechanisms to introduce these “speculation barriers”. If it were easy it would be easily fixed. There needs to be fundamental design changes for side-effect free speculation.
Fundamental design changes are needed to make it fast, specifically fast enough to be acceptable to most users. Just fixing it is trivial: nuke speculation.
Nuking speculation is only trivial if that is already “designed in”. Perhaps okay for new processors. The “speculation barrier” is what is on the table for current designs that may be able to be introduced by micro-code.
Nuking (all, not just BTB) branch prediction should also work (aside from meltdown I'm not aware of other ways speculation could be exploited, but not 100% sure) and seems likely to be possible with microcode.
If neither is possible, vendors should be offering compelling technical explanations of why it's not possible rather than refusing to even speak about it. The appearance is that they DON'T WANT TO FIX IT in any way that would look bad wrt performance.
Old P5 and maybe early P6/ppro era chips had an MSR to disable branch prediction, which would also be likely to suffice if made available again.
The current proposed fix is to add a “speculation barrier” instruction which needs to be explicitly inserted before vulnerable code (LFENCE on x86); which in itself is a very hard problem that requires alias analysis and proving bounds e.g. hard to do with a language like C.
This is insufficient and not a fix. ALL CODE is potentially sensitive/vulnerable. Spectre does not require a victim process with a JIT/VM running untrusted code; that's just the easiest vector. Some "pure-data" vectors are known and they will continue to emerge, forever.
It likely may not be or it would have been done. Speculation is on the fast path. It’s a fundamental design issue. It’s possible to do whatever was previously baked in for access via micro-code. e.g. expensive things like flushing the BTB.
I think you're missing the obvious motivation not to: Intel doesn't want to ship a security feature that makes their chip 75% slower or worse.
Indeed it is plausible to design a CPU that speculates without visible cache side effects, but it requires some very fundamental changes such as changes to caches and cache coherence protocols. Doing so while maintaining similar performance to existing designs is a hard problem.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.