I don't believe for a second that nobody came up with this idea before. I believe that nobody until now had the motivation to spend the time actually trying to confirm that it's a problem by developing a PoC. Most people would have given up on the idea simply because CPU vendors are not expected to make such a fundamental mistake.

The mistake is clear from the design - thats why all CPU vendors are vulnerable to variants of the same bugs.

Previously side channel attacks like this have been seen by the security community as unreliable things which only work in very specific cases and have to be averaged over millions of runs.

This attack shows a side channel which is general purpose, reliable, and fast.

> The mistake is clear from the design

There is no fundamental reason why speculative instructions should be allowed to mutate the cache.

OTOH the contention-based side channel attack on speculation has been public knowledge for over a decade. [1]

[1] Z. Wang and R. B. Lee, "Covert and Side Channels Due to Processor Architecture," 2006 22nd Annual Computer Security Applications Conference (ACSAC'06), Miami Beach, FL, 2006, pp. 473-482. doi: 10.1109/ACSAC.2006.20

> There is no fundamental reason why speculative instructions should be allowed to mutate the cache.

There is: hundreds of instructions can be in flight speculatively at the same time, especially if you take hyperthreading into account. Good luck rolling them all back.

The question is not whether the cache should be mutated during speculative execution. It's what kinds of speculative execution are allowed, and in some cases it's not even clear if fences should be placed by the programmer (whack-a-mole style), the compiler (not sure how) or the processor (probably not). It's non-obvious enough that how to solve it is to some extent a research problem.

About Meltdown, it was well known since even before that speculative execution has to stop at security boundaries.