Great read! Some boiled-down takeaways:<p>- Predictor updates may be deferred until sometime <i>after</i> a branch retires. Makes sense, otherwise I guess you'd expect that branches would take longer to retire!<p>- Dispatch-serializing instructions don't stall the pipeline for pending updates to predictor state. Also makes sense, considering you've already made a distinction between "committing the result of the branch instruction" and "committing the result of the prediction".<p>- Privilege-changing instructions don't stall the pipeline for pending updates either. Also makes sense, but only if you can guarantee that the privilege level is consistent between making/committing a prediction. Otherwise, you might be creating a situation where predictions generated by code in one privilege level may be committed to state used in a different one?<p>Maybe this is hard because "current privilege level" is not a single unambiguous thing in the pipeline?
Good to see Kaveh Razavi, he used to teach at my uni in the Vrije Universiteit in Amsterdam :) The course Hardware Security was crazy cool and delved into stuff lijke this.
Anyone know how this relates to the Training Solo attack that was just disclosed? <a href="https://www.vusec.net/projects/training-solo/" rel="nofollow">https://www.vusec.net/projects/training-solo/</a>
If CPU brach predictor had bits of information readily available to check buffer boundaries and privilege level of the code, all this would be much easier to prevent. But apparently that will only happen when we pry out the void* from the cold C programmers' hands and start enriching our pointers with vital information.
I wonder if there's similar gaps in AMD hardware? Seems like speculative execution is simply an extremely hard to patch vulnerability in a share processor space so I wonder how AMD has avoided it.
> Closing these sorts of gaps requires a special update to the processor’s microcode. This can be done via a BIOS or operating system update and should therefore be installed on our PCs in one of the latest cumulative updates from Windows.<p>Why mention only Windows, what about Linux users?
I wonder if there's any way to recover for Intel. They don't have anything worthwhile on the market, R&D takes a lot of time and their foundries are a constant source of losses as they're inferior compared to the competition.<p>On top of that x86 seems to be pushed out more and more by ARM hardware and now increasingly RISC-V from China. But of course there's the US chip angle - will the US, especially after the problems during Covid, let a key manufacturer like Intel bite the dust?
Just to make sure I got this right, at this point in time there are patches out for all major operating systems that can mitigate this/apply relevant microcode to mitigate it?
<a href="https://scholar.harvard.edu/files/mickens/files/theslowwinter.pdf" rel="nofollow">https://scholar.harvard.edu/files/mickens/files/theslowwinte...</a><p>"Unfortunately for John, the branches made a pact with Satan and quantum mechanics [...] In exchange for their last remaining bits of entropy, the branches cast evil spells on future generations of processors. Those evil spells had names like “scaling-induced voltage leaks” and “increasing levels of waste heat” [...] the branches, those vanquished foes from long ago, would have the last laugh."
> <i>All intel processors since the 9th generation (Coffee Lake Refresh) are affected by Branch Privilege Injection. However, we have observed predictions bypassing the Indirect Branch Prediction Barrier (IBPB) on processors as far back as 7th generation (Kaby Lake).</i><p>From that piece of text on the blog, I don‘t quite unterstand if Kaby Lake CPUs are affected or not.
As it seems a lot of people are not aware that this one is a newer generation of branch predictor issue. You can see that Intels eIBRS doesn't mitigate the problems and make them susceptible to attacks. To prevent bigger issues the issue was released after Intel has been informed of the Issue and most systems are patched in the meantime.
The end-user processor slowdowns from Spectre and Meltdown mitigations were fairly substantial. Has anyone seen an estimate of how much the microcode updates for this new speculative vulnerability are going to cost in terms of slowdown?
Since the cloud is someone else's computer, and someone else's shared CPU, is cloud hosting (including vps) potentially impacted?<p>Look forward to learning how this can be meaningfully mitigated.
Haven’t we been here before? It seems like it’s very similar to the branch prediction exploits of the late 2010s. Is there something particularly novel about this class of exploits?
Is there an easy way to run a browser on some phone/tablet and everything else on a desktop just to isolate the web and JS from accessing your desktop?
yeah this just makes me wanna see real world numbers on the slowdown, cuz honestly all these microcode fixes feel like trading off years of speed for maybe a little more peace of mind - you ever think well actually move off this cycle or is it just here to stay?