linux-kernel - Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3ECBB974-C6F0-47A7-94B6-3646347F1CC2@nutanix.com>
Date: Wed, 26 Nov 2025 03:00:19 +0000
From: Jon Kohler <jon@...anix.com>
To: Dave Hansen <dave.hansen@...el.com>
CC: Sohil Mehta <sohil.mehta@...el.com>,
        Dave Hansen
	<dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, Borislav
 Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar
	<mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra
	<peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Pawan Gupta
	<pawan.kumar.gupta@...ux.intel.com>,
        Nikolay Borisov <nik.borisov@...e.com>,
        Alex Murray <alex.murray@...onical.com>,
        Andrew Cooper
	<andrew.cooper3@...rix.com>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh
 the revisions that determine old_microcode



> On Nov 20, 2025, at 7:39 PM, Dave Hansen <dave.hansen@...el.com> wrote:
> 
> On 11/20/25 11:27, Dave Hansen wrote:
>> On 11/20/25 11:13, Sohil Mehta wrote:
>>> The early loading probably gets affected because intel_get_platform_id()
>>> relies on boot_cpu_data which isn't initialized when load_ucode_bsp() is
>>> called very early.
>> Good point, and thanks for finding those bugs!
>> 
>> We can probably just move back to building the vfm value from CPUID
>> directly as opposed to reading it from boot_cpu_data.
> 
> OK, here's a theoretically fixed up series. I actually booted this on
> real hardware and made sure I didn't break microcode loading in general:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_daveh_devel.git_log_-3Fh-3Dold-2Ducode-2Dplatform&d=DwICaQ&c=s883GpUCOChKOHiocYtGcg&r=NGPRGGo37mQiSXgHKm5rCQ&m=Aj3XdJqTpjECR_fyNML3SeMNT46oTwjdjYY5YqPSZ0k2Er9zbK7KbRrCX3jepXXq&s=XwRvvtN9Ch3mUF4-T-_lRIJBcpDpHgt5ebg5Hgl8ylg&e= 
> The actual hardware I tested on was this one:
> 
> { .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6,  .model = 0x7a, .steppings = 0x0002, .platform_mask = 0x01, .driver_data = 0x42 },
> 
> For testing, I added a 100% made up but matching CPU
> model/family/stepping that has (made up) later microcode and a
> (made up) higher platform ID that I added to the ucode-defs.h file:
> 
> { .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6,  .model = 0x7a, .steppings = 0x0002, .platform_mask = 0x02, .driver_data = 0x43 },
> 
> Everything seemed to work OK for me in my limited but nonzero
> amount of testing.
> 
> Any additional testing or eyeballs on the code would be appreciated.
> I'll post it for real in a day or two if it all looks OK.

Looks like it works, no longer complains of old microcode, loading works

Tested with 6.18 rc6 + our internal patch queue + your latest patches

Before, it was broken as reported before. After, works good.

[    2.451421] smpboot: CPU0: Intel(R) Xeon(R) Gold 5416S (family: 0x6, model: 0x8f, stepping: 0x8)
[    3.503508] microcode: Current revision: 0x2b000643
[    3.503510] microcode: Updated early from: 0x2b000620

tested-by/reported-by Jon Kohler <jon@...anix.com <mailto:jon@...anix.com>>

Thanks for tackling this!

Cheers,
Jon