How do you know this?

I think it's worth noting that it's entirely possible, that if you are a CPU execution pipeline designer that you think about memory loads/stores, L1 cache, branch prediction and speculative execution, and it occurs to you that the cache gets polluted by spec exec, and the branches can be security checks.

But the solution is simple. If the branch is important, wait for it. (Load it into L1 cache before the branch - use a memory barrier.)

The fact that this is not in any ISA docs is a likely pointer toward the possibility that it in fact hadn't occurred to them.

These attacks are the same as any new invention. Easy to see once you've grasped the concept.

Have you got a reference for that statement? Because my interpretation of what has been said so far is that AMD deliberately chose not to allow speculative dependent loads that crossed privilege boundaries by enforcing permission checks on all reads whereas Intel chose to permit all loads & rely on the fixup at the retirement stage of the pipeline to enforce privilege boundaries.

Happy to be proven wrong however.

Because they knew it was an obvious security risk?

What are you even arguing here?

If I observe fact X which is "bleeding obvious", then it's not my responsibility to tell the world about X.

Of course this stuff isn't "bleeding obvious", but I'm going to assume that the AMD engineers thought that it was "obvious enough" to not explicitly to tell the world about it.

Besides... do you have any idea what kind of NDAs those engineers are going to have to sign?

There is a difference between following good security practices (gratuitous isolation, defensive design) and having exploits ready to show the world how valuable it is. Noone was claiming AMD knew of such exploits beforehand.

Perhaps whoever thought about it assumed it was obvious enough that others would have realized it as well. It may simply have never occurred to them that it was worth sharing.