linux-kernel - RE: [PATCH v3] x86/cpu: Fix x86_match_cpu() to match just X86_VENDOR

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: Fri, 17 May 2024 18:13:06 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Dave
 Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H.
 Peter Anvin" <hpa@...or.com>, "Peter Zijlstra (Intel)"
	<peterz@...radead.org>, Uros Bizjak <ubizjak@...il.com>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>, Arnd Bergmann <arnd@...db.de>, Mateusz Guzik
	<mjguzik@...il.com>, Thomas Renninger <trenn@...e.de>, Greg Kroah-Hartman
	<gregkh@...e.de>, Andi Kleen <ak@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: RE: [PATCH v3] x86/cpu: Fix x86_match_cpu() to match just
 X86_VENDOR_INTEL

>> 	for (m = match; m->flags & X86_CPU_ID_FLAG_ENTRY_VALID; m++) {
>
> Yeah, makes sense at a first glance.
>
> This'll keep the terminators "{}" unchanged so that we don't have to
> touch all those gazillion places and it'll explicitly state that an
> entry is valid or not.

> But the devil's in the detail, as always...

Yes. One detail is that there are places not using the X86_MATCH macros.

E.g. in arch/x86/crypto/aesni-intel_glue.c there is:

static const struct x86_cpu_id zmm_exclusion_list[] = {
        { .vendor = X86_VENDOR_INTEL, .family = 6, .model = INTEL_FAM6_SKYLAKE_X },
	...
};

This one (and likely most/all others) will be fixed by the remaining patches in my new families[1] series.

But I'll need to audit to check that I got them all before changing x86_match_cpu() to
only look at m->flags.

-Tony

[1] I'll work on rebasing the remaining patches in that series. I think all but a couple of trees
that have conflicting changes in linux-next have now been pulled into mainline.