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 18:12:04 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Luck, Tony" <tony.luck@...el.com>
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

On Thu, Mar 28, 2024 at 05:00:59PM +0000, Luck, Tony wrote:
> It's essentially free to do this, and it makes the code more robust. It
> becomes impossible to check model without also checking vendor
> and family at the same time.

I see that but if we want to use CPUID(1).EAX, there's no vendor in
there.

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))

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.

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.

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

I'd say.

-- 
Regards/Gruss,
    Boris.

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