linux-kernel - Re: [PATCH] x86/cpu/intel: Add RFDS mitigation quirk for Goldmont and Tremont-D

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: <4da8a846-d4c5-4ff9-a50b-4ea94dab14d7@intel.com>
Date: Thu, 29 Jan 2026 08:37:41 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: moontorise@....kr, x86@...nel.org, Thomas Gleixner <tglx@...nel.org>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>
Cc: "H . Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>,
 Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
 Josh Poimboeuf <jpoimboe@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/cpu/intel: Add RFDS mitigation quirk for Goldmont and
 Tremont-D

On 1/29/26 07:43, moontorise@....kr wrote:
> Intel's "Guidance for Security Issues on Intel Processors" [1] lists
> Goldmont (06_5CH) and Tremont-D (06_86H) as capable of mitigating
> Register File Data Sampling (RFDS) [2] starting from specific microcode
> revisions as defined in the consolidated product CPU model table.

I went looking and wasn't able to find this. It's also not clear which
specific microcode version is/was connected to the RFDS mitigation.

I rather dislike that table. <grumble> <grumble>

I also don't see a microcode update for INTEL_ATOM_TREMONT_D ever having
been published:

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.git

which makes me a bit suspicious. That would _seem_ to mean that
everything on that CPU is BIOS-loaded or that no update has ever been
published. If there's never been an update, then there's no reason for
us to check the microcode version.

> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 63b0f9aa9b3e..3480d9ddc046 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -513,6 +513,7 @@
>  						      * and purposes if CLEAR_CPU_BUF_VM is set).
>  						      */
>  #define X86_FEATURE_X2AVIC_EXT		(21*32+20) /* AMD SVM x2AVIC support for 4k vCPUs */
> +#define X86_FEATURE_RFDS_CLEAR		(21*32+21) /* Clear register file via VERW */
>  
>  /*
>   * BUG word(s)
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 83f51cab0b1e..20c1fa47f04b 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -650,7 +650,8 @@ static const char * const rfds_strings[] = {
>  
>  static inline bool __init verw_clears_cpu_reg_file(void)
>  {
> -	return (x86_arch_cap_msr & ARCH_CAP_RFDS_CLEAR);
> +	/* Check the synthetic flag for CPUs not reporting RFDS_CLEAR via MSR. */
> +	return (x86_arch_cap_msr & ARCH_CAP_RFDS_CLEAR) || boot_cpu_has(X86_FEATURE_RFDS_CLEAR);
>  }

Please don't do this.

Just axe verw_clears_cpu_reg_file(). Move over to only checking
X86_FEATURE_RFDS_CLEAR only. This patch should be broken into two. The
first patch does this move, and adds:

	if (x86_arch_cap_msr & ARCH_CAP_RFDS_CLEAR)
		setup_force_cpu_cap(X86_FEATURE_RFDS_CLEAR);

>  static void __init rfds_select_mitigation(void)
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 646ff33c4651..02f4ac2069f8 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -325,6 +325,22 @@ static void early_init_intel(struct cpuinfo_x86 *c)
>  		setup_clear_cpu_cap(X86_FEATURE_PGE);
>  	}
>  
> +	/*
> +	 * Goldmont and Tremont-D support RFDS mitigation via VERW,
> +	 * but do not enumerate it in MSRs. Explicitly set the capability
> +	 * based on the microcode revision. (Tremont-D requires stepping 7).
> +	 */
> +	switch (c->x86_vfm) {
> +	case INTEL_ATOM_GOLDMONT:
> +		if (c->microcode >= 0x28)
> +			set_cpu_cap(c, X86_FEATURE_RFDS_CLEAR);
> +		break;
> +	case INTEL_ATOM_TREMONT_D:
> +		if (c->x86_stepping == 7 && c->microcode >= 0x4c000026)
> +			set_cpu_cap(c, X86_FEATURE_RFDS_CLEAR);
> +		break;
> +	}

No, this just isn't how we do these. Please make an x86_cpu_id[] array
and use x86_match_cpu() on it. You can even match on steppings in those.

I also despise these microcode version lists. Let's just use:

	boot_cpu_has_bug(X86_BUG_OLD_MICROCODE);