linux-kernel - Re: [PATCH v2 2/2] x86/cpu/intel: Add implicit RFDS mitigation 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: <8fc7cdab-b4a5-4899-8032-842884cb7540@intel.com>
Date: Fri, 30 Jan 2026 14:28:02 -0800
From: Sohil Mehta <sohil.mehta@...el.com>
To: Joongsun Moon-Lee <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 v2 2/2] x86/cpu/intel: Add implicit RFDS mitigation for
 Goldmont and Tremont-D

On 1/30/2026 4:33 AM, Joongsun Moon-Lee wrote:

>  static void init_intel(struct cpuinfo_x86 *c)
>  {
>  	early_init_intel(c);
> @@ -612,6 +622,10 @@ static void init_intel(struct cpuinfo_x86 *c)
>  	if (x86_match_cpu(zmm_exclusion_list))
>  		set_cpu_cap(c, X86_FEATURE_PREFER_YMM);
>  
> +	if (x86_match_cpu(implicit_rfds_list) &&
> +	    !boot_cpu_has_bug(X86_BUG_OLD_MICROCODE))
> +		setup_force_cpu_cap(X86_FEATURE_RFDS_CLEAR);
> +

I do not understand the usage of X86_BUG_OLD_MICROCODE over here.
"old_microcode" by design is a moving target. That would imply that this
feature/mitigation would depend on keeping the microcode up-to-date.

Let's say for example that a new microcode blob gets released for
INTEL_ATOM_GOLDMONT for some unrelated reason. Do we want the kernel
behavior for RFDS_CLEAR feature to change just because someone didn't
perform the update?

If this is intentional, we should probably add a comment here or near
"struct x86_cpu_id implicit_rfds_list" to describe this choice.

I see that Dave suggested this in the previous review to avoid checks
such as (c->microcode >= 0x4c000026). But, that seems redundant in some
sense.

You could simply do:
	if (x86_match_cpu(implicit_rfds_list)
		setup_force_cpu_cap(X86_FEATURE_RFDS_CLEAR);

The old microcode mechanism will work independently and complain
separately about the user not running with the latest microcode.
Old microcode by definition means:
"CPU has old microcode, it is surely vulnerable to something."

This way Linux behavior for this feature doesn't vary from one kernel to
another.