Re: [PATCH 2/2] x86, microcode: Add option to allow downgrading of microcode

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Fri, 24 Jan 2014, Andi Kleen wrote:
> For testing purposes it can be useful to downgrade microcode.
> Normally the driver only allows upgrading.

The code is not prepared to work correctly when downgrading is allowed, in
the presence of shadowed microcode.  When a firmware request results in more
than one microcode for the same cpuid, with overlapping pf_mask, the code
*depends* on the "never downgrade" logic to work.

Shadowed microcode *is* currently distributed by Intel, and as an artifact
of the f-m-s grouping, it is *guaranteed* to trigger the issue.  When the
issue triggers, what microcode will be selected to be uploaded to the core
depends *only* on the order of the microcodes in the firmware file.

I see no documentation of this fact anywhere, and it is *anything* but
obvious.

That extremely obnoxious Intel microcode license forbids anyone to fix the
pf_mask metadata fields to remove shadowing, so we ship that stuff as-is to
in the distros.  It *will* hit users.

Also, since you're going to mess with this, why don't you implement the
correct semanthics for microcode with the sign bit set?  Making it signed
actually makes the current code behaviour worse.

Refer to: http://lkml.org/lkml/2011/3/21/522

Note that I was wrong about negative revision microcode not being found in
the wild.  Intel has shipped entry-level server boards with pre-release
microcode several times, even on BIOS updates, and you're likely to get
access to such pre-release microcode if you're dealing with Intel firmware
partners that has full access to microcode updates.

-- 
  "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