linux-kernel - Re: [PATCH] x86/cpu: Sort the Intel microcode defines by Family-model-stepping

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: <c12b6500-46a7-4e61-91db-da4ce654aae6@intel.com>
Date: Tue, 15 Jul 2025 11:02:51 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: Dave Hansen <dave.hansen@...el.com>, Dave Hansen
	<dave.hansen@...ux.intel.com>, <x86@...nel.org>
CC: Borislav Petkov <bp@...en8.de>, "H . Peter Anvin" <hpa@...or.com>, "Thomas
 Gleixner" <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/cpu: Sort the Intel microcode defines by
 Family-model-stepping

On 7/14/2025 8:33 PM, Dave Hansen wrote:
> On 7/14/25 19:00, Sohil Mehta wrote:
>> Keeping the Intel microcode defines sorted by Family-model-stepping is
>> crucial to its long-term maintainability. This would prevent unnecessary
>> changes and duplicate entries whenever they are updated.
> 
> I've been procrastinating putting my script that generated that file
> into the tree. But we should probably just have it do the sorting and
> just update the file the next time we update the microcode versions.
> 

The output was a result of exactly that. I am preparing the script to
merge it into the kernel. But when I ran the script, I couldn't
accurately reproduce what is currently there in intel-ucode-defs.h.

I added the sorting to keep it consistent in the future. But, I figured
for a particular microcode release, let's say 29f82f7429c
("microcode-20241029 Release") we should have a unique and matching
intel-ucode-defs.h.

Sure, we could start enforcing this with the next time we update the
header. However, since the file may be shared across stable kernels, it
seemed valuable to change the first version as well.

> But either way, I'm not concerned about maintainability. I just re-run
> the script and regenerate the whole file each time.

Yeah, the sorting is mainly to make it easier to review what is changing
in the file with every update.

Anyway, I'll leave the maintainability aspect of this up to you :)