linux-kernel - Re: [PATCH v6 4/5] x86/bugs: Declutter vulnerable CPU list

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: <542cfd1b-65f8-4fa9-811e-d70850d0cf9a@intel.com>
Date: Thu, 6 Mar 2025 07:18:55 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org
Cc: daniel.sneddon@...ux.intel.com, tony.luck@...el.com,
 linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
 linux-perf-users@...r.kernel.org, Josh Poimboeuf <jpoimboe@...nel.org>,
 Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>,
 "Liang, Kan" <kan.liang@...ux.intel.com>,
 Andrew Cooper <andrew.cooper3@...rix.com>,
 Brice Goglin <brice.goglin@...il.com>,
 Mario Limonciello <mario.limonciello@....com>,
 Perry Yuan <Perry.Yuan@....com>, Dapeng Mi <dapeng1.mi@...ux.intel.com>
Subject: Re: [PATCH v6 4/5] x86/bugs: Declutter vulnerable CPU list

On 3/5/25 23:13, Pawan Gupta wrote:
...
>  #define VULNWL_INTEL(vfm, whitelist)		\
> -	X86_MATCH_VFM(vfm, whitelist)
> +	X86_MATCH_VFM(INTEL_##vfm, whitelist)

I think the new VFM code may have thrown you off here. Doing HASWELL_X
is not as nice as INTEL_HASWELL_X because, while you can grep for it, it
won't work when you're looking for full identifiers like with ctags or
cscope.

Also, this is just putting the "INTEL" in the macro instead of the VFM.
I'm not sure there's much value in doing:

	VULNWL_INTEL(ALDERLAKE_L, ...)	

over:

	X86_MATCH_VFM(INTEL_ALDERLAKE_L, ...)

Before the 'vfm' stuff, we needed X86_VENDOR_INTEL in there somewhere.
But now that it's built in to INTEL_ALDERLAKE_L, we don't.