At this point I think speculation attacks are almost being accepted as the price of having high performance processors. It’s almost impossible to rewind all non-architectural state when you hit a mis-speculated branch.
the mitigations just have bugs, and bugs can be fixed
I’m not convinced it won’t be a thing of the past after some time
I’m afraid as long as you have shared architecture you will always have side channel data leaks. The only true mitigation is dedicated resources per compute item. So dedicated cores, dedicated cache etc
CPUs have so many cores these days, that seems like a perfectly reasonable option. Declare a process ‘security sensitive,’ give it it’s own core & memory, then wipe it when done.
I can’t wait for a non speculative execution, non spooked, not glowing cpu. I honestly don’t care how slow it would be, so long it can run Linux, firefox and VSCodium (or if forced, i’ll learn Neo Vim). I just hope RISC will make my dreams real.
I’m no expert here, but I’m pretty sure branch prediction logic is not part of the instruction set, so I don’t see how RISC alone would “fix” these types of issues.
I think you have to go back 20-30 years to get CPUs without branch prediction logic. And VSCodium is quite the resource hog (as is the modern web), so good luck with that.
Why do AMD always have such a terrible response to these vulnerabilities? The article seems to suggest they’ve just decided to ignore this. They almost left zen 2 CPUs out of the Sinkclose fix and they took ages to release the Zenbleed fix for consumer CPUs despite it being available for enterprise ones when the vulnerability was released. And their microcode patches on Linux are only for server CPUs, desktop CPUs have to hope that their motherboard vendor releases a firmware update fairly quickly