[lkml]   [2013]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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:

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

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

"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

 \ /
  Last update: 2013-12-15 02:01    [W:0.056 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site