[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4160661b-cfda-42db-97c5-51e2725fa059@intel.com>
Date: Tue, 20 Jan 2026 10:18:17 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>, linux-kernel@...r.kernel.org
Cc: sohil.mehta@...el.com, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Jon Kohler <jon@...anix.com>, Pawan Gupta
<pawan.kumar.gupta@...ux.intel.com>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Thomas Gleixner <tglx@...nel.org>, Tony Luck <tony.luck@...el.com>,
x86@...nel.org
Subject: Re: [PATCH 0/6] x86/cpu: Take Intel platform into account for old
microcode checks
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?
Powered by blists - more mailing lists