public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: moontorise@cfg.kr, x86@kernel.org,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/cpu/intel: Add RFDS mitigation quirk for Goldmont and Tremont-D
Date: Thu, 29 Jan 2026 08:37:41 -0800	[thread overview]
Message-ID: <4da8a846-d4c5-4ff9-a50b-4ea94dab14d7@intel.com> (raw)
In-Reply-To: <20260129154342.3867-1-moontorise@cfg.kr>

On 1/29/26 07:43, moontorise@cfg.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);




  reply	other threads:[~2026-01-29 16:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-29 15:43 [PATCH] x86/cpu/intel: Add RFDS mitigation quirk for Goldmont and Tremont-D moontorise
2026-01-29 16:37 ` Dave Hansen [this message]
2026-01-30 12:33 ` [PATCH v2 0/2] " Joongsun Moon-Lee
2026-01-30 12:33   ` [PATCH v2 1/2] x86/cpu: Refactor RFDS mitigation to use X86_FEATURE_RFDS_CLEAR Joongsun Moon-Lee
2026-01-30 21:40     ` Borislav Petkov
2026-01-30 12:33   ` [PATCH v2 2/2] x86/cpu/intel: Add implicit RFDS mitigation for Goldmont and Tremont-D Joongsun Moon-Lee
2026-01-30 17:50     ` Dave Hansen
2026-02-02 12:32       ` Joongsun Moon-Lee
2026-01-30 22:28     ` Sohil Mehta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4da8a846-d4c5-4ff9-a50b-4ea94dab14d7@intel.com \
    --to=dave.hansen@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=moontorise@cfg.kr \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox