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 19:38:11 +0200
From: Borislav Petkov <bp@...en8.de>
To: Tony Luck <tony.luck@...el.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	Uros Bizjak <ubizjak@...il.com>,
	Rick Edgecombe <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,
	patches@...ts.linux.dev
Subject: Re: [PATCH v3] x86/cpu: Fix x86_match_cpu() to match just
 X86_VENDOR_INTEL

On Fri, May 17, 2024 at 10:21:34AM -0700, Tony Luck wrote:
> diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c
> index 8651643bddae..996f96cfce68 100644
> --- a/arch/x86/kernel/cpu/match.c
> +++ b/arch/x86/kernel/cpu/match.c
> @@ -39,7 +39,7 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
>  	struct cpuinfo_x86 *c = &boot_cpu_data;
>  
>  	for (m = match;
> -	     m->vendor | m->family | m->model | m->steppings | m->feature;
> +	     m->vendor | m->family | m->model | m->steppings | m->feature | m->flags;

I think this should not do anything implicit even if it is correct but
should explicitly check

	if (!(m->flags & X86_CPU_ID_FLAG_VENDOR_VALID))
		continue;

I don't have a clear idea how exactly yet - I need to play with it.

Maybe this stupid flow in the loop should be finally fixed into
something more readable and sensible...

Thx.

-- 
Regards/Gruss,
    Boris.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ