Is this news?
I, and a few others with similar levels of knowledge, have been painstakingly attempting to explain this until exhaustion from day one. Our communal moniker aside, El Reg's community contains an amazing brain trust.
- Rule #1 of business is that the customer is king.
- General consumers don't understand security, and do not care unless they personally are inconvenienced.
- - General consumers actively punish companies that provide security at the cost of their convenience.
- - General consumers actively punish companies that provide more expensive solutions with no apparent benefit.
The outcome of the above is that anyone selling into the general consumer market is either going to be like Intel (selling vulnerable product) or Blackberry (driven out of the market).
From a technical standpoint, data leaking through the cache response times is core to the existence of a cache on the part. THIS DOES NOT DEPEND ON SPECULATIVE EXECUTION. Speculative execution permits rapid reading out of the data, but even without it, if I have access to a wall clock, I can tell if my data has been ejected from the cache or not. This is a data leak.
This leakage, however, is not subject to attacker control. Various strategies by defensive applications or the OS can prevent an attacker from deriving usable information this way.
Speculative execution, in and of itself, does not affect the situation. Speculative execution that bypasses memory protections, however, very much does.
So, what was the situation in the nineties? Speculative execution with memory protection bypass provided consumers with a substantial speed improvement. Yes, we all knew that there was a theoretic risk of exploit. We tried (not me personally, the industry) AND FAILED to realize that exploit. So the designs were shipped. And for more than twenty years, there was no publicly known exploit.
While I have strongly condemned Intel's response to the discovery, there is simply no honest way to condemn them for the decision that they made in the nineties to ship this design.
I will also point out that I have been aggressively throwing shade on these software "fixes" since they have been coming out. Memory protection bypassing in the hardware is not something software can fix. I said this a year ago. Its truth is obvious to anyone that has played around at that level.
Again, the potential fixes are as follows:
1) Turn off all caching.
2) Turn off all speculative fetching.
3) Replicate ALL caching at ALL levels so that cache ejections due to speculative fetching are recovered. (I have become more pessimistic about this over time for various reasons--but it roughly doubles cache sizes & adds a lot of logic. It also is not clear that this would defend against an indexed load being speculatively fetched from an address space controlled by the attacker--and I do not believe that gadgets of this sort are avoidable.)
4) Enforce memory protection during speculative execution.
5) Ban untrusted code.
Anyone who as done significant work designing or validating microprocessors understands just how bad options 1-4 are from a performance/watt standpoint. Which is why I've been talking about 5 for the last few months.
Dedicated machines running only trusted applications are can safely ignore Spectre-class attacks. This will give them a HUGE performance/watt bonus over Spectre-secure machines. The market is going to bifurcate over this--and we should rejoice, because once it does, there is a chance, however small, that x86 will finally get the boot from the consumer space.