Messages in this thread | | | Date | Tue, 30 Jan 2018 16:19:14 -0200 | From | Henrique de Moraes Holschuh <> | Subject | Re: [PATCH] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel |
| |
On Tue, 30 Jan 2018, Borislav Petkov wrote: > On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote: > > So much for the theory. That's not going to work. If the boot cpu has the > > feature then the alternatives will have been applied. So even if the flag > > mismatch can be observed when a secondary CPU comes up the outcome will be > > access to a non existing MSR and #GP. > > Yes, with mismatched microcode we're f*cked. > > So my question is: is there such microcode out there or is this > something theoretical which we want to address?
Old mixed-stepping systems would have mismatched microcode even when everything went right, just because they had different processor steppings that took different microcode.
Those systems could have mismatched CPU flags (regardless of their microcode being up-to-date or not) simply because the processor with the newer stepping might have more features. This happened at least once during the FSB-era Xeons. I came across several (large three-letter vendor) x86 Intel-based servers that were in such a condition, *all using official parts*, because they got upgraded with a second processor sometime after they were boght, and the part number delivered by said three-letter vendor was a newer stepping.
You will notice those were all *fully and officially supported* hardware configurations, and documented as such in the processor specification updates.
There was also a crop of UEFI and BIOSes out there that would not properly update the microcode on all processor cores, several years ago.
> And if I were able to wish, I'd like to blacklist that microcode in > dracut so that it doesn't come anywhere near my system.
Well, the microcode update of a core can soft-fail, and the fact is that we don't handle such failures at all in any way. Not that I know what would be the right error handling for something like this... kicking the processor offline (or refusing to online it) might be a good way to handle it. And one could at least retry once... Anyway, we don't even report it, which is certainly Not Good Enough.
That said, iucode-tool v2.3, released a couple days ago, can do revision-based blacklisting of microcode[1], if you want to fine-comb the stuff you're going to ship to your users, etc.
[1] iucode-tool is somewhat widely used *outside* of the Fedora/RedHat ecosystem, but not even packaged by Fedora, AFAIK. So, it won't be relevant to several people in the To/CC list ;-)
-- Henrique Holschuh
| |