On Wed, 2018-01-24 at 08:49 -0200, Henrique de Moraes Holschuh wrote: > On Wed, 24 Jan 2018, David Woodhouse wrote: > > > > I'm kind of tempted to turn it into a whitelist just by adding 1 to the > > microcode revision in each table entry. Sure, that N+1 might be another > > microcode build that also has issues but never saw the light of day... > Watch out for the (AFAIK) still not properly documented where it should > be (i.e. the microcode chapter of the Intel SDM) weirdness in Skylake+ > microcode revision. Actually, this is related to SGX, so anything that > has SGX. > > When it has SGX inside, Intel will release microcode only with even > revision numbers, but the processor may report it as odd (and will do so > by subtracting 1, so microcode 0xb0 is the same as microcode 0xaf) when > the update is loaded by the processor itself from FIT (as opposed as > being loaded by WRMSR from BIOS/UEFI/OS). > > So, you could see N-1 from within Linux if we did not update the > microcode, and fail to trigger a whitelist (or mistrigger a blacklist). That's OK. If they ship a fixed 0x0200003E firmware for SKX, for example, which appears as 0x0200003D when it's loaded from FIT, that's still >= 0x0200003C *and* !(<0x0200003D) if we were to do that. In fact, the code for the "whitelist X+1" vs. "blacklist X" approach is *entirely* equivalent; it's purely a cosmetic change. Because !(< X) ≡ ≥ (X+1) The *real* change here is that for ∀ SKU, we are being asked to blacklist all microcode revisions <= 0xFFFFFFFF¹ for now, and change that only once new microcode is actually released. Every time, and then get people to rebuild their kernels because they can *use* the features from the new microcode. ¹(OK, *there's* a functional difference between whitelist and blacklist approach. But we'll never actually see 0xffffffff so that's not important right now :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
