Messages in this thread | | | Date | Sat, 14 Dec 2013 22:40:16 -0200 | From | Henrique de Moraes Holschuh <> | Subject | Re: [PATCH 2/2] x86, microcode: Add option to allow downgrading of microcode |
| |
On Fri, 13 Dec 2013, Henrique de Moraes Holschuh wrote: > 2. This change has unintended side-effects that ought to be at least > documented: > > In "allow downgrade" mode, should you send a microcode pack with several > microcodes to the kernel, and more than one of them might apply to the > running processor (when the pf_flags of two or more of the microcodes are > not disjoint), either the first or the last (I didn't check) will be the > one chosen. > > I've seen in the wild microcodes where both rev X and Y (when Y > X) could > be applied to a specific processor, but rev X was intended to more > processors (more bits set in pf_mask) than rev. Y. I don't think they were > in the same Intel microcode update datafile, but it can happen. In normal > upgrade-only mode this works correctly, while in your proposed downgrade > mode, it won't.
Well, tracked it down to:
/lib/firmware/intel-ucode/0f-04-0a 001: sig 0x00000f4a, pf mask 0x5c, 2005-12-14, rev 0x0004, size 2048 002: sig 0x00000f4a, pf mask 0x5d, 2005-06-10, rev 0x0002, size 2048
/lib/firmware/intel-ucode/0f-04-08 001: sig 0x00000f48, pf mask 0x5f, 2005-06-30, rev 0x0007, size 3072 002: sig 0x00000f48, pf mask 0x01, 2006-05-08, rev 0x000c, size 3072 003: sig 0x00000f48, pf mask 0x02, 2008-01-15, rev 0x000e, size 3072
And these are microcodes still being distributed in the latest Intel microcode bundle (2013-09-06). They're for old processors, but still... if it happened once and it is still being distributed like that, it can happen again.
-- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
| |