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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
