No, I think it is relevant. What are the odds that the NSA was not aware of this and already exploiting it?
Was this really an unintentional "bug"
No, it wasn't, on the balance of probabilities, deliberate.
I can quite see how the engineers would miss this. Their targets would have been meeting performance goals and providing the security
specified by the architecture, not meeting the security goals that someone with adversarial security experience would consider desirable - which would include quashing any possible side channels. (I can tell you from experience of trying to design systems to be covert channel free that this is
very hard to do on small systems, and
immensely hard to do on large complex systems like the super-scalar, out of order, execution engines that modern CPUs are.)
Speculative execution (and super-scalar processors) are all about trying to
reduce latency. Protection mechanisms
introduce latency. So you try and run the protection checks
in parallel with the speculative execution and only stop the speculative execution once you've got results from the protection checks. This means that you will almost certainly use some protected data for speculative execution before you know the results of the protection checks for that data If you don't, you lose some of the latency advantages of speculative execution.
However, this has side effects, one of which - as we have seen - is polluting the cache with speculative fetches. An adversarial security-minded mindset would have spotted this as an information leak and at least provided an option to stall the speculative execution pipeline with interlocks between protected actions and protection check results, resulting in no cache pollution and hence no information leak.
The problem is one of designing the chipset with a performance mindset and not being aware of the security trade-offs of some of those performance enhancing tricks. In a performance mindset it's OK that a speculative execution that falls foul of a protection check simply fails to retire* those instructions rather than undoes all the side effects of that speculative execution. Done that way there is no
explicit access to that data and the
architectural security model is satisfied. As we have seen, this is not enough to satisfy an adversarial security model that is intolerant of implicit partial data leaks.
*retire in this sense means 'write back the results to architectural registers once the speculative execution becomes non-speculative'.