It looks like they expose some MSR to control the branch predictor, see:
> Note: IBRS is not required in order to isolate branch predictions for SMM or SGX enclaves
Perhaps this microcode update exposes a feature which was originally to protect these two modes? But that would mean that Intel did think about leaks through the branch predictor, only didn't make the logical leap that this could be an issue also for normal ring0/ring3...
1: https://arxiv.org/abs/1611.06952 (Nov '16)
No secret channel to communicate with Linux Kernel developers? No coordinated effort? Last minute findings?
On this thread https://lkml.org/lkml/2018/1/4/174 looks like that the author is disclosing the info on the last minute.
Did the vendors ignore the disclosure initially and begin to change tactics later in the game? Based on how certain vendors have been characterizing this in their PR, I wouldn't be surprised if they didn't take the problem seriously originally.
[]: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
First prove it works and then prove it can be made better and faster ...
Everybody stalls for time when the stakes are this high. How long can I reasonably spend tying to turn this into a small problem before I have to go public with it?
Saying it’s a bigger problem than it turns out to be is a PR nightmare of its own. If there was a cheap fix then you cried wolf and killed your reputation just as dead.
The chatter is all about how CPU manufacturers screwed up, but there is a much more alarming issue here, I think: the apparent irresponsibility of the people who published the flaws before the security teams and the users could mitigate them. Perhaps there was a reason for accelerated public disclosure, but so far this makes no sense to me.