linux-kernel - Re: [PATCH] x86/mm: Don't disable INVLPG if "incomplete Global INVLPG flushes" is fixed by microcode

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] [day] [month] [year] [list]

Message-ID: <6cb0333cb0e60aa9f7e914af26c605d075f90d61.camel@xry111.site>
Date: Mon, 25 Mar 2024 02:31:37 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Andy Lutomirski <luto@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>,  Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar
 <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, "H. Peter Anvin"
 <hpa@...or.com>, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/mm: Don't disable INVLPG if "incomplete Global
 INVLPG flushes" is fixed by microcode

On Sun, 2024-03-24 at 11:29 -0700, Dave Hansen wrote:
> On 3/24/24 10:06, Xi Ruoyao wrote:
> > +/*
> > + * INVLPG issue is fixed with intel-microcode-20240312 for all
> > + * affected models.  This table is taken from the release note
> > + * of this microcode release.
> > + */
> 
> That comment is much more changelog material than code comment material.
> 
> > +static const struct x86_cpu_desc invlpg_miss_fixed_ucode[] = {
> > +	INTEL_CPU_DESC(INTEL_FAM6_ALDERLAKE,		2, 0x34),
> > +	INTEL_CPU_DESC(INTEL_FAM6_ALDERLAKE,		5, 0x34),
> > +	INTEL_CPU_DESC(INTEL_FAM6_ALDERLAKE_L,		3, 0x432),
> > +	INTEL_CPU_DESC(INTEL_FAM6_ALDERLAKE_L,		4, 0x432),
> > +	INTEL_CPU_DESC(INTEL_FAM6_ATOM_GRACEMONT,	0, 0x15),
> > +	INTEL_CPU_DESC(INTEL_FAM6_RAPTORLAKE,		1, 0x122),
> > +	INTEL_CPU_DESC(INTEL_FAM6_RAPTORLAKE_P,		2, 0x4121),
> > +	INTEL_CPU_DESC(INTEL_FAM6_RAPTORLAKE_P,		3, 0x4121),
> > +	INTEL_CPU_DESC(INTEL_FAM6_RAPTORLAKE_S,		2, 0x34),
> > +	INTEL_CPU_DESC(INTEL_FAM6_RAPTORLAKE_S,		5, 0x34),
> > +	{}
> > +};
> 
> Why is this listing individual steppings?  That seems nuts when the
> issue affects *all* steppings or at least the invlpg_miss_ids[] table
> says it affects all steppings.
> 
> The right way to do this is to take the existing table:
> 
>         INTEL_MATCH(INTEL_FAM6_ALDERLAKE   ),
>         INTEL_MATCH(INTEL_FAM6_ALDERLAKE_L ),
>         INTEL_MATCH(INTEL_FAM6_ATOM_GRACEMONT ),
> 
> and simply add the fix version:
> 
>         INTEL_WHATEVER(INTEL_FAM6_ALDERLAKE, 	  0x034),
>         INTEL_WHATEVER(INTEL_FAM6_ALDERLAKE_L, 	  0x432),
>         INTEL_WHATEVER(INTEL_FAM6_ATOM_GRACEMONT, 0x015),
> 
> Then you do:
> 
> 	c = x86_match_cpu(invlpg_miss_ids);
> 	if (boot_cpu_data.microcode >= c->data)
> 		return 0; // no mitiagtion
> 	// affected, do mitigation
> 
> Then there's *one* table listing each model once and no steppings.  I
> thought there's another example of this _somewhere_ but I couldn't find
> it in two minutes of grepping.

Hmm, I also thought there should be this thing but I couldn't find it...
Let me try again.

-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University