I would have expected, if I thought to ask, that items were not added to the cache or were removed from the cache if the branch was not retired.
I would have expected, if I thought to ask, that items were not added to the cache or were removed from the cache if the branch was not retired.
Intel isn't being sneaky, speculative reading was a standard and accepted feature for out of order processors for over 20 years (remember it affects ARM,AMD,Apple,IBM etc as well). Speculative reading privileged memory while unprivileged was a big mistake though.
Shipping or not, it illustrates, that Intel was not unique.
https://www.amd.com/en/corporate/speculative-execution
https://googleprojectzero.blogspot.co.uk/2018/01/reading-pri...
It's also not the scariest variant, it's easily fixed (performance degradation aside), doesn't require a microcode update to be fixed hence is 100% software mitigated, doesn't allow you to cross between guest and host memory address spaces and isn't remotely exploitable.
On the other hand variant 1 and 2 are much scarier because they are the complete opposite of Meltdown.
And Meltdown was the easiest to exploit. Spectre is "bad" because it affects everyone, but it's less exploitable than Intel's Meltdown.
Meltdown is the easiest to exploit and the easiest to fix it’s also the least scary one as far as compromises go.
While it's more easily exploited, it's also patchable with minimal performance impact, unlike Spectre in general.
Let's not throw the baby out with the bathwater here. I don't think the problem is that speculative execution is not as invisible as it was once believed. The problem is more of awareness and documentation. If there was an option to disable speculative execution and awareness of the associated security issues from the beginning, I don't think anyone would have a problem with using it for a performance boost where it was safe to do so. The problem is there was an industry wide assumption that it wasn't a problem that turned out to be wrong.