Spectre how & why
Despite my previous comment, I am not inclined to be overly harsh on the designers for these issues.
The thing to understand is the difference between architectural state (a-state) and microarchitectural state (m-state). The m-state of a processor is everything that is needed to determine, for any input, what the m-state of the processor will be in the next cycle. This is not a tautology or circularity. We see, for instance, that we need to know the state of the L1 cache to know what will be in the register file. Therefore, the L1 cache is part of the m-state, and we need to include everything that affect the L1 cache as part of the m-state as well. The a-state is everything needed to know the result of executing the next instruction. The difference between the two is mostly caches, but there is another matter. Given the m-state, and a set of inputs, you can know the final m-state. But the a-state is not closed. In particular, performance registers and clocks are part of the a-state, but they are not predicted by the a-state. You can load from one of these registers, but the final state of that register is know known. Therefore, the a-state is NOT enough to predict the result of a series of instructions. Did they teach you that in school? Probably not so that it stood out.
For consumer grade processors, the contract is strictly about the a-state. The m-state might be presented, but it is subject to change at any time. In particular, if a bug is found the a processor, a patch might be issued to the microcode in the processor to fix the bug. This fix is extremely likely to impact the performance of the processor under at least some circumstances. That is, the m-state behavior is thrown out to fix the a-state. Of course, manufacturers are strongly motivated to keep the m-state changes minimal.
Design teams have been told to deliver a-state promises at maximum speed.
Spectre is not a violation of the a-state promises. It is therefore not a "bug" in the sense that the processor is failing to behave as advertised. It is a failure to isolate state, and therefore a security failure in the presence of untrusted code.
Note that at the front of every manual I saw in the 1996-2006 timeframe, there was a big notice just inside the cover that the processor was not cleared for use with information classified "confidential" or higher. Perhaps they could have been a bit more explicit, but processor designers were disclaiming side channel-free products.
---
So, what to expect? 1) Variants of these bugs are going to continue to dribble out. The only way to avoid them on existing product is to entirely turn off speculative execution, which might not even be possible. If it is possible, expect huge drops in performance. 50x would not surprise me. 2) Designs to get around this issue are going to require huge reworking of the caches. Expect cache memory sizes to halve. This will be a major performance hit. 3) Given the size of the performance hit, I expect compute utilization to bifurcate. In trusted computing environments, the benefits of speculative executing are going to support a continuing market for speculative execution. In general computing, not. I anticipate this split appearing in the cloud.
---
In another discussion, someone mentioned targeting contention for execution units as a variant. Execution unit contention might even happen with designs that are merely pipelined. Defending against that would involve adding execution units sufficient to ensure that it cannot happen. Given my experience, don't hold your breath.
Biting the hand that feeds IT
