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

Message-ID: <319db7f3-7ce1-4096-a168-e5869c7a42f6@intel.com>
Date: Sun, 24 Mar 2024 11:29:26 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Xi Ruoyao <xry111@...111.site>, Dave Hansen <dave.hansen@...ux.intel.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 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.