linux-kernel - RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo

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]

Date: Thu, 28 Mar 2024 16:56:37 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: "x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct
 cpuinfo_x86

>>  	__u8			x86_stepping;
>
> Why are you leaving out stepping?

There are only a handful of places where stepping is significant in CPU model
specific checks (mostly errata and side-channel security stuff). I didn't want to
have to invent new #define names for each stepping. E.g. there are about
three separate steppings of INTEL_SKYLAKE_X out in the wild. It would
be messy to have three #defines and add them in all the stepping independent
code paths.

> And since we want to simplify all this, why aren't we replacing all
> f/m/s checks by using the whole CPUID(1).EAX u32 instead?
>
> Then the macros need to build that CPUID leaf simply.

I could make the raw format of the #define values be CPUID(1).EAX
with the stepping masked out. But then I'd need to add a new field to
the structure instead of overlaying with the vendor/family/model
fields.

-Tony