Fork

Posted Jul 13, 2022 12:46 UTC (Wed) by eru (subscriber, #2753)
In reply to: Fuck. by Subsentient
Parent article: The "Retbleed" speculative execution vulnerabilities

I wonder at which point the workarounds for speculative execution vulnerabilities slow the CPU more than what speculative execution speeds it up?
Also, could these workarounds be a fool's errand, because the vulnerabilities drop out of how speculative execution works by design, so they will always be present in some form if the CPU speculates?

Fork

Posted Jul 19, 2022 17:10 UTC (Tue) by anton (subscriber, #25547) [Link]

No, these vulnerabilities come from treating microarchitectural state as being irrelevant.

The CPU architects know very well how to implement speculation properly: they do it for architectural state; if a speculative register change or memory write turns out to be wrong, it is never committed to permanent state.

For microarchitectural state (e.g., caches) they thought (and maybe still do) that they don't need to go to the lengths that they do for architectural state and can, e.g., permanently load a speculatively loaded cache line into the L1 cache, thus providing a side channel to attackers.