x86/ucode/intel: Fix handling of microcode revision

For Intel microcode blobs, the revision field is signed (as documented in the
SDM) and negative revisions are used for pre-production/test microcode (not
documented publicly anywhere I can spot).

Adjust the revision checking to match the algorithm presented here:

  https://software.intel.com/security-software-guidance/best-practices/microcode-update-guidance

This treats pre-production microcode as always applicable, but also production
microcode having higher precedent than pre-production.  It is expected that
anyone using pre-production microcode knows what they are doing.

This is necessary to load production microcode on an SDP with pre-production
microcode embedded in firmware.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This commit is contained in:
Andrew Cooper committed 2021-01-27 20:29:43 +00:00
1 parent 754865c298
commit aa1b136ff1
1 file changed
+13 -2
+13 -2
View File
@@ -33,7 +33,7 @@
struct microcode_patch {
uint32_t hdrver;
uint32_t rev;
int32_t rev;
uint16_t year;
uint8_t day;
uint8_t month;
@@ -222,12 +222,23 @@ static int microcode_sanity_check(const struct microcode_patch *patch)
return 0;
}
/*
* Production microcode has a positive revision. Pre-production microcode has
* a negative revision.
*/
static enum microcode_match_result compare_revisions(
uint32_t old_rev, uint32_t new_rev)
int32_t old_rev, int32_t new_rev)
{
if ( new_rev > old_rev )
return NEW_UCODE;
/*
* Treat pre-production as always applicable - anyone using pre-production
* microcode knows what they are doing, and can keep any resulting pieces.
*/
if ( new_rev < 0 )
return NEW_UCODE;
return OLD_UCODE;
}
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.