linux-kernel - Re: [PATCH v2] scripts/x86/intel: Add a script to update the minimum ucode revisions

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250822182447.GHaKi176wVuSsNMmi4@fat_crate.local>
Date: Fri, 22 Aug 2025 20:24:47 +0200
From: Borislav Petkov <bp@...en8.de>
To: Sohil Mehta <sohil.mehta@...el.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	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>,
	Dave Hansen <dave.hansen@...el.com>,
	Nikolay Borisov <nik.borisov@...e.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] scripts/x86/intel: Add a script to update the minimum
 ucode revisions

On Fri, Aug 22, 2025 at 11:03:10AM -0700, Sohil Mehta wrote:
> Currently, we have a static list of microcode revisions that determine
> old_microcode. So, it needs to be periodically updated as and when new
> microcode releases are made.

Who is expected to do that and when?

> Also, some folks might want to have a custom enforcement of the minimum
> microcode revisions (be it stricter or relaxed).

I don't understand how that relates to the script.

> The script makes it easier to update intel-ucode-defs.h by generating
> output in the specific format it needs. Having this live in the kernel
> makes it easier to find whenever needed

What?! -ENOPARSE.

> and also be in sync with the header format if it ever changes.

I have a big problem with people being able to willy-nilly update this header
and then things starting to fail because someone updated the header but it was
wrong and then we have to go debug that too.

Update to the header needs to happen in very controlled manner, when you have
released tested microcode and have decided to deprecate old microcode.

Not just lightheartedly shoot out a new header version out because shit got
updated somewhere.

So, actually, this script should NOT be in the kernel but in some repo
internal in Intel.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette