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]

Message-ID: <SJ1PR11MB6083D8BB65748452B204ED8AFC3B2@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Thu, 28 Mar 2024 18:32:35 +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

> And frankly, the x86 vendor is a Linux thing so I wouldn't mind if
> checks are
>
>	if (c->x86_vendor  == X86_VENDOR... &&
>	    c->cpuid_1_eax == MACRO_BUILD_CPUID_1_EAX(fam, model, stepping))

That hurts my eyes compared to:

	if (c->x86_vfm == INTEL_DOUGLASCOVE)

>
> Anyway, using CPUID(1).EAX is just a suggestion so that we don't have to
> invent our own format and convert to and fro.

All the conversion is at compile time to generate the values for the CPU model
name #defines.

> And that would be advantageous when we convert to dealing with
> CPUID(1).EAX values everywhere and we compare them straightaway. We'd
> need macros only when we need only some data elements from that leaf.

It's a humungous amount more code churn. Most of the changes in this set were
achieved with some simple sed scripts (followed by hand massage to adjust TABs
to make things pretty because lengths of strings are different).

Take a look at a few of the patches that implement this change and consider
how they would look based on a CPUID(1).EAX value.

> And since that leaf's layout is commonly known, the conversion errors
> should be at a minimum...
>
> I'd say.

I don't think the format is really that big an issue. Including stepping in the
format adds complexity to a thousand places these checks are made while
only being useful in a few dozen.

-Tony