Goldmont and Tremont-D CPUs support RFDS mitigation via VERW but do not
enumerate the RFDS_CLEAR bit in the IA32_ARCH_CAPABILITIES MSR.

Force X86_FEATURE_RFDS_CLEAR for these models in init_intel() to enable
the mitigation automatically. For Tremont-D, limit the quirk to stepping 7,
as stepping 5 does not support mitigation according to Intel's guidance [1].

To ensure safety, only enable this quirk when X86_BUG_OLD_MICROCODE is
not set, guaranteeing the microcode implements the VERW side-effect.

Verification was performed on an Intel NUC8CCHKR (Celeron N3350 / Goldmont)
with microcode 0x48, confirming the status change from
"Vulnerable: No microcode" to "Mitigation: Clear Register File".

[1] https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html#tab-blade-1-1

Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lore.kernel.org/all/20260129154342.3867-1-moontorise@cfg.kr/
Signed-off-by: Joongsun Moon-Lee <moontorise@cfg.kr>
---
 arch/x86/kernel/cpu/intel.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 646ff33c4651..9867ca383621 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -531,6 +531,16 @@ static const struct x86_cpu_id zmm_exclusion_list[] = {
 	{},
 };
 
+/*
+ * These CPUs mitigate RFDS via VERW but do not enumerate the RFDS_CLEAR bit
+ * in IA32_ARCH_CAPABILITIES MSR.
+ */
+static const struct x86_cpu_id implicit_rfds_list[] = {
+	X86_MATCH_VFM(INTEL_ATOM_GOLDMONT,		0),
+	X86_MATCH_VFM_STEPS(INTEL_ATOM_TREMONT_D, 7, 7,	0),
+	{},
+};
+
 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);
+
 	/* Work around errata */
 	srat_detect_node(c);
 
-- 
2.52.0

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.

On 1/30/26 04:33, Joongsun Moon-Lee wrote:
...
> Force X86_FEATURE_RFDS_CLEAR for these models in init_intel() to enable
> the mitigation automatically. For Tremont-D, limit the quirk to stepping 7,
> as stepping 5 does not support mitigation according to Intel's guidance [1].

Thank $DEITY for the CSV:

> https://github.com/intel/Intel-affected-processor-list/blob/main/Intel_affected_processor_list.csv

$ csvtool namedcol "CPUID Family_Model,Stepping,MCU Update,Register File
Data Sampling (RFDS) (Floating Point/Integer / Single
Instruction/Multiple Data) - CVE-2023-28746 - INTEL-SA-00898"
Intel_affected_processor_list.csv \
	| egrep '^06_86H|06_5CH'

Yields:

06_5CH,A,0x28,      MCU+Software
06_86H,5,0x4c000026,No planned mitigation
06_86H,7,0x4c000026,MCU+Software

Which is actually readable, unlike the HTML table.

But, honestly, other than the table saying "MCU+Software", I don't see
any indication that VERW does what you want it to do on these CPUs.

Intel's guidance[1] only says:

	... software should only apply the VERW mitigations as an RFDS
	mitigation if RFDS_CLEAR is enumerated.

So I think you're going _entirely_ on the "MCU+Software" in the
table/csv above. Is there anything else? It sounds like you haven't
actually tested in VERW does what you want it to.

> +/*
> + * These CPUs mitigate RFDS via VERW but do not enumerate the RFDS_CLEAR bit
> + * in IA32_ARCH_CAPABILITIES MSR.
> + */
> +static const struct x86_cpu_id implicit_rfds_list[] = {
> +	X86_MATCH_VFM(INTEL_ATOM_GOLDMONT,		0),
> +	X86_MATCH_VFM_STEPS(INTEL_ATOM_TREMONT_D, 7, 7,	0),
> +	{},
> +};

Please make this look like all the other lists and make an attempt to
vertically align things.


1.
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html

After further investigation and empirical testing on Goldmont N3350,
I am withdrawing this patch series (both Patch 1 and 2).

Based on the feedback and my subsequent analysis, here is the summary of
why I've concluded these patches should not be merged:

1. Latency Verification: To verify if the forced RFDS mitigation actually
   triggers VERW, I measured the average latency of the getpid() syscall
   by comparing a kernel with the mitigation enabled against one
   with it disabled.
   - Mitigation Disabled: ~177 cycles
   - Mitigation Enabled: ~188 cycles
   While this ~6% overhead suggests that VERW is executing some level of
   buffer clearing, it does not specifically prove RFDS-level mitigation.

2. PoC Verification: I ran a PoC to verify Register File clearing via VERW,
   but the results were inconclusive. Due to the complexities of register
   restoration and potential PoC limitations, I could not reliably
   demonstrate RFDS mitigation.

3. Microcode Timeline Mismatch: While Intel's documentation suggests
   a fix is available, the latest microcode for Goldmont N3350 (rev 0x48)
   was released in 2022, predating the 2024 RFDS disclosure.
   Without a confirmed microcode update explicitly clearing Register File,
   forcing this quirk would risk reporting a false "Mitigated" status.

Conclusion: As a security-sensitive part of the kernel, it is better
to leave the status as "Vulnerable: No microcode" rather than misreporting
a mitigation that cannot be verified against the known microcode release
and PoC results.

Thank you for the critical feedback, which prompted me to perform
this deeper dive into the hardware's actual behavior

Best regards,
Joongsun Moon-Lee