There was a report[1] that CPUs running updated microcode were being
reported as running old microcode. The reason is that the old
microcode list neglects to take the platform ID into account.

The platform ID is an Intel-only construct that allows CPUs that
otherwise have the same model/family/stepping to take different
microcode revisions. The microcode loader itself already checks this.
Only the recent "old_microcode" checker failed here.

Treat the platform ID as a peer of model/family/stepping. Store it
in 'struct cpuinfo_x86', enable matching on it with with 'struct
x86_cpu_id', and flesh out the 'old_microcode' list with it.

This fixes the report of an inaccurate, false positive in the
'old_microcode' vulnerability file.

1. https://lore.kernel.org/all/38660F8F-499E-48CD-B58B-4822228A5941@nutanix.com/

Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: x86@kernel.org
Cc: Jon Kohler <jon@nutanix.com>

On 1/19/26 11:50, Dave Hansen wrote:
> This fixes the report of an inaccurate, false positive in the
> 'old_microcode' vulnerability file.

BTW... I'm open to other ways of fixing this. This series is bigger than
I'd like. It also crept into silly areas like the PECI driver, which
isn't great.

Using the x86_match_cpu() infrastructure means both munging the
existing, widely-used 'x86_cpu_id' and 'cpuinfo_x86' structures ... all
for what is essentially a single user.

But, the overhead is minimal because both structures had some holes and
the platform_id is small.

It might also have been possible to cram the microcode revision and
platform ID into the ->driver_data in cpu_latest_microcode[]. But that
would not have been straightforward on 32-bit since the kernel_ulong_t
driver_data is full with the microcode revision.

Anyone have any better ideas?

On Mon, Jan 19, 2026 at 11:50:47AM -0800, Dave Hansen wrote:
> There was a report[1] that CPUs running updated microcode were being
> reported as running old microcode. The reason is that the old
> microcode list neglects to take the platform ID into account.
> 
> The platform ID is an Intel-only construct that allows CPUs that
> otherwise have the same model/family/stepping to take different
> microcode revisions. The microcode loader itself already checks this.
> Only the recent "old_microcode" checker failed here.
> 
> Treat the platform ID as a peer of model/family/stepping. Store it
> in 'struct cpuinfo_x86', enable matching on it with with 'struct
> x86_cpu_id', and flesh out the 'old_microcode' list with it.
> 
> This fixes the report of an inaccurate, false positive in the
> 'old_microcode' vulnerability file.
> 
> 1. https://lore.kernel.org/all/38660F8F-499E-48CD-B58B-4822228A5941@nutanix.com/

I tested this patchset on two machines:

Alder Lake (F-M-S/PI = 06-9a-04/80). The microcode-20251111 from Intel
lists different versions for platform IDs 0x80 and 0x40 of 06-9a-04. Before
these patches, only the machine with platform ID 0x40 would have falsely
complained about the old microcode. Mine did not, as expected. I applied
this patchset and tweaked the file intel-ucode-defs.h to fake a later
microcode version. I could verify that my machine was identified correctly
and distinguished from 06-9a-04/40.

Kaby Lake (F-M-S/PI = 06-8e-09/80). There are two platform IDs for this
model and stepping, but the latest microcode for both is 0xf6. Neither of
these processors would have reproduced the reported false positive. Again,
I tweaked intel-ucode-defs.h with a fake .data_driver value and could
verify that my stepping and platform ID were identified correctly.

Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>