linux-kernel - Re: [PATCH 2/5] x86/cpu: Expose only stepping min/max interface

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: <20241213162443.GGZ1xfyw_EZBrn1i4B@fat_crate.local>
Date: Fri, 13 Dec 2024 17:24:43 +0100
From: Borislav Petkov <bp@...en8.de>
To: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de,
	kan.liang@...ux.intel.com, mingo@...nel.org, peterz@...radead.org,
	tony.luck@...el.com, pawan.kumar.gupta@...ux.intel.com
Subject: Re: [PATCH 2/5] x86/cpu: Expose only stepping min/max interface

On Fri, Dec 06, 2024 at 11:38:32AM -0800, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@...ux.intel.com>
> 
> The x86_match_cpu() infrastructure can match CPU steppings. Since
> there are only 16 possible steppings, the matching infrastructure goes
> all out and stores the stepping match as a bitmap. That means it can
> match any possible steppings in a single list entry. Fun.
> 
> But it exposes this bitmap to each of the X86_MATCH_*() helpers when
> none of them really need a bitmap. It makes up for this by exporting a
> helper (X86_STEPPINGS()) which converts a contiguous stepping range
> into the bitmap which every single user leverages.
> 
> Instead of a bitmap, have the main helper for this sort of thing
> (X86_MATCH_VFM_STEPPING()) just take a stepping range. This ends up
> actually being even more compact than before.

Yap, better.

> Leave the helper in place (renamed to __X86_STEPPINGS()) to make it
> more clear what is going on instead of just having a random GENMASK()
> in the middle of an already complicated macro.
> 
> One oddity that I hit was this macro:
> 
> #define VULNBL_INTEL_STEPPINGS(vfm, max_stepping, issues)                 \
>        X86_MATCH_VFM_STEPPINGS(vfm, X86_STEPPING_MIN, max_stepping, issues)
> 
> It *could* have been converted over to take a min/max stepping value
> for each entry. But that would have been a bit too verbose and would
> prevent the one oddball in the list (INTEL_COMETLAKE_L stepping 0)
> from sticking out.
> 
> Instead, just have it take a *maximum* stepping and imply that the match
> is from 0=>max_stepping. This is functional for all the cases now and
> also retains the nice property of having INTEL_COMETLAKE_L stepping 0
> stick out like a sore thumb.
> 
> Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
> Suggested-by: Ingo Molnar <mingo@...nel.org>
> ---
> 
>  b/arch/x86/include/asm/cpu_device_id.h |   15 +++---
>  b/arch/x86/kernel/apic/apic.c          |   18 +++----
>  b/arch/x86/kernel/cpu/common.c         |   78 ++++++++++++++++-----------------
>  b/drivers/edac/i10nm_base.c            |   20 ++++----
>  b/drivers/edac/skx_base.c              |    2 
>  b/include/linux/mod_devicetable.h      |    2 
>  6 files changed, 69 insertions(+), 66 deletions(-)

You missed a spot:

drivers/edac/i10nm_base.c:951:90: error: macro "X86_MATCH_VFM_STEPPINGS" requires 4 arguments, but only 3 given
  951 |         X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_DARKMONT_X,  X86_STEPPINGS(0x0, 0xf), &gnr_cfg),
      |                                                                                          ^
In file included from drivers/edac/i10nm_base.c:10:
./arch/x86/include/asm/cpu_device_id.h:221: note: macro "X86_MATCH_VFM_STEPPINGS" defined here
  221 | #define X86_MATCH_VFM_STEPPINGS(vfm, min_step, max_step, data)  \
      | 
drivers/edac/i10nm_base.c:951:9: error: ‘X86_MATCH_VFM_STEPPINGS’ undeclared here (not in a function)
  951 |         X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_DARKMONT_X,  X86_STEPPINGS(0x0, 0xf), &gnr_cfg),
      |         ^~~~~~~~~~~~~~~~~~~~~~~
make[4]: *** [scripts/Makefile.build:194: drivers/edac/i10nm_base.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:440: drivers/edac] Error 2
make[2]: *** [scripts/Makefile.build:440: drivers] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/mnt/kernel/kernel/2nd/linux/Makefile:1989: .] Error 2
make: *** [Makefile:251: __sub-make] Error 2

> diff -puN drivers/edac/i10nm_base.c~zap-X86_STEPPINGS drivers/edac/i10nm_base.c
> --- a/drivers/edac/i10nm_base.c~zap-X86_STEPPINGS	2024-12-06 11:33:16.187148838 -0800
> +++ b/drivers/edac/i10nm_base.c	2024-12-06 11:33:16.191148995 -0800
> @@ -938,16 +938,16 @@ static struct res_config gnr_cfg = {
>  };
>  
>  static const struct x86_cpu_id i10nm_cpuids[] = {
> -	X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_TREMONT_D,	X86_STEPPINGS(0x0, 0x3), &i10nm_cfg0),
> -	X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_TREMONT_D,	X86_STEPPINGS(0x4, 0xf), &i10nm_cfg1),
> -	X86_MATCH_VFM_STEPPINGS(INTEL_ICELAKE_X,	X86_STEPPINGS(0x0, 0x3), &i10nm_cfg0),
> -	X86_MATCH_VFM_STEPPINGS(INTEL_ICELAKE_X,	X86_STEPPINGS(0x4, 0xf), &i10nm_cfg1),
> -	X86_MATCH_VFM_STEPPINGS(INTEL_ICELAKE_D,	X86_STEPPINGS(0x0, 0xf), &i10nm_cfg1),
> -	X86_MATCH_VFM_STEPPINGS(INTEL_SAPPHIRERAPIDS_X,	X86_STEPPINGS(0x0, 0xf), &spr_cfg),
> -	X86_MATCH_VFM_STEPPINGS(INTEL_EMERALDRAPIDS_X,	X86_STEPPINGS(0x0, 0xf), &spr_cfg),
> -	X86_MATCH_VFM_STEPPINGS(INTEL_GRANITERAPIDS_X,	X86_STEPPINGS(0x0, 0xf), &gnr_cfg),
> -	X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_CRESTMONT_X,	X86_STEPPINGS(0x0, 0xf), &gnr_cfg),
> -	X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_CRESTMONT,	X86_STEPPINGS(0x0, 0xf), &gnr_cfg),
> +	X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_TREMONT_D,	0x0, 0x3, &i10nm_cfg0),
> +	X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_TREMONT_D,	0x4, 0xf, &i10nm_cfg1),
> +	X86_MATCH_VFM_STEPPINGS(INTEL_ICELAKE_X,	0x0, 0x3, &i10nm_cfg0),
> +	X86_MATCH_VFM_STEPPINGS(INTEL_ICELAKE_X,	0x4, 0xf, &i10nm_cfg1),
> +	X86_MATCH_VFM_STEPPINGS(INTEL_ICELAKE_D,	0x0, 0xf, &i10nm_cfg1),
> +	X86_MATCH_VFM_STEPPINGS(INTEL_SAPPHIRERAPIDS_X,	0x0, 0xf, &spr_cfg),
> +	X86_MATCH_VFM_STEPPINGS(INTEL_EMERALDRAPIDS_X,	0x0, 0xf, &spr_cfg),
> +	X86_MATCH_VFM_STEPPINGS(INTEL_GRANITERAPIDS_X,	0x0, 0xf, &gnr_cfg),
> +	X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_CRESTMONT_X,	0x0, 0xf, &gnr_cfg),
> +	X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_CRESTMONT,	0x0, 0xf, &gnr_cfg),

Aren't those supposed to be:

	X86_MATCH_VFM_STEPPINGS(INTEL_ATOM_CRESTMONT,	X86_STEPPING_MIN, X86_STEPPING_MAX, &gnr_cfg),

And while we're adding new defines, can we shorten them too?

	X86_MATCH_VFM_STP(INTEL_ATOM_CRESTMONT,	X86_STP_MIN, X86_STP_MAX, &gnr_cfg),

all that "STEPPING" is screaming at me! :-P

-- 
Regards/Gruss,
    Boris.

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