It appears the retpoline fixes don't work in Skylake or later (it's smart enough to speculate out of it?) and will require new support for IBRS/IBPB in the microcode to mitigate.
I was wondering the same thing earlier. This doesn't feel like a disclosure that's had anywhere near ~6 months put into it.
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.
The Ubuntu page that was on HN earlier [] claims that they were notified in early November. I have no idea if kernel people (as opposed to distro people) got notified earlier.
Especially microcode updates. Microcode is just a giant obscure binary for everyone outside of Intel. If there was a mitigation possible via a microcode update this could have been published months before disclosure without any meaningful risk.
IIRC Intel employs people to work on the linux kernel on behalf oh Intel. Either Intel fumbled or it isn't that easy to circumvent the problem plaging Intel's processors with a software hack.
Exactly this. Apparently, the details of the attack have been published in official paper(s) before the security teams of major OSes could prepare and make publicly available mitigating patches for the users. There is no patch for Debian 8.0 (Jessie), or for Qubes OS, for example.
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.
> 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...
j_coder|8 years ago
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.
Pyxl101|8 years ago
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.
mook|8 years ago
[]: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
MertsA|8 years ago
geezerjay|8 years ago
effie|8 years ago
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.
bpye|8 years ago
cesarb|8 years ago
> 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...
contrarian_|8 years ago
gcbirzan|8 years ago