Thread by @lavados

Speculative Side-Channel Attacks is misleading terminology and usually used incorrectly. We should all avoid using it and @intel, you should avoid using it too. Not only because it is misleading, but because it hinders successful communication on mitigations.
Let me elaborate:

A side-channel attack uses measurements of side effects to gather enough *meta data* (power consumption, runtime, cache state, etc) to *infer* secret information.
#meltdown #spectre #zombieload and related attacks and variants do not leak meta data. They leak the actual data.

There is no need to infer secret information from meta data, there is no meta data involved. Hence, they are *no side-channel attacks*.

"But they use flush+reload". Sure, but that doesn't make the attack a side-channel attack. Let's assume the following:

You have a bug in $cloud which allows you to run a program in another tenants VM. Full privileges but no network access for the process. You decide to exfiltrate the data via a cache covert channel. Does that make the entire attack a side-channel attack? Clearly not.

So what about speculative. #spectre exploits speculative execution. #meltdown does not, #zombieload does not. Speculative execution refers to execution based on a prediction. In #meltdown and #zombieload there are no predictions involved.

Now I've heard various arguments why it still must be speculative execution. "But the CPU speculates that the instruction won't fault".
Well, but then any strict in-order pipeline must be called speculative execution: fetch and decode happen before we know what happens next.

Another one: "speculation is just a normal English word and it naturally includes all these attacks because it just refers to anything that is not yet certain."
Exactly. It's imprecise, and it is wrong for many attacks including #meltdown and #foreshadow and #zombieload.

When the processor forwards the data in these attacks it often *knows* that this data is not the right one. It is not speculating. It knows that it's incorrect and still does it.

Now, to the last part: why would we care and why should @intel care?

Because: Many of these attacks are almost trivial to mitigate (possibly with new silicon required) - there are silicon fixes for #meltdown #Foreshadow and #zombieload.
All these (we call them meltdown-type) attacks can be eliminated at little or no cost.

The case of #spectre and speculative execution is different. Here, the processor does not do any wrong things, it does not forward the wrong data, it does exactly what we want the CPU to do. It just speculates, to gain performance.
This is a problem well beyond some CPU design.

Keep them separate in communication: one class is just bug fixing, the other requires fundamental design changes.
Mixing them suggests incorrectly that #meltdown-type attacks are just as fundamental design problems and just as "unfixable" as #spectre and not fixable bugs.