arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/bugs.c | 3 ++- arch/x86/kernel/cpu/intel.c | 16 ++++++++++++++++ 3 files changed, 19 insertions(+), 1 deletion(-)
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.
However, unlike newer models, these processors do not enumerate the
RFDS_CLEAR bit (Bit 28) in the IA32_ARCH_CAPABILITIES MSR even with the
required microcode. This suggests that while the implementation for
clearing the register file via VERW is present, the architectural
reporting bit is missing. Consequently, these systems remain identified
as "Vulnerable: No microcode" because the kernel strictly relies on the
MSR bit.
Introduce a quirk to explicitly set the X86_FEATURE_RFDS_CLEAR feature
flag based on the microcode revisions defined in Intel's guidance [1]:
- Goldmont (06_5CH): 0x28 or later
- Tremont-D (06_86H) Stepping 7: 0x4c000026 or later
Also, update verw_clears_cpu_reg_file() to check for this feature flag
in addition to the MSR bit.
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
[2] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html
Signed-off-by: Joongsun Moon-Lee <moontorise@cfg.kr>
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/bugs.c | 3 ++-
arch/x86/kernel/cpu/intel.c | 16 ++++++++++++++++
3 files changed, 19 insertions(+), 1 deletion(-)
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);
}
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;
+ }
+
check_memory_type_self_snoop_errata(c);
/*
base-commit: 271605ee159b528465e451e0be90baf8103b52bc
--
2.52.0Greetings, I would like to thank Dave Hansen for the insightful feedback on the first version; the suggested refactoring has significantly improved the clarity and structure of this series. This is the second version of the patch series to support RFDS mitigation specifically for Goldmont and Tremont-D processors. While most affected processors received microcode updates [1] to enumerate the RFDS_CLEAR bit, Goldmont and Tremont-D support the VERW-based mitigation but fail to report it via MSR. This series provides an implicit quirk to enable protection for these models. Changes since v1: - Split the original patch into two parts as suggested by Dave Hansen: 1. x86/cpu: Refactor RFDS mitigation to use X86_FEATURE_RFDS_CLEAR 2. x86/cpu/intel: Add implicit RFDS mitigation for Goldmont and Tremont-D - Improved the quirk detection logic: Instead of manual revision checks, it now leverages X86_BUG_OLD_MICROCODE. Technical Note on Tremont-D: According to Intel's guidance [2], Tremont-D stepping 7 is listed as "MCU + Software" mitigatable. However, as no microcode update has been observed for this model, patch 2 identifies Tremont-D stepping 7 implicitly to enable VERW mitigation. This approach aligns with Intel's documented strategy, even though the actual VERW side-effects on this microcode cannot be independently verified. [1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20240312 [2] 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 Link: https://lore.kernel.org/all/20260129154342.3867-1-moontorise@cfg.kr/ Signed-off-by: Joongsun Moon-Lee <moontorise@cfg.kr> Joongsun Moon-Lee (2): x86/cpu: Refactor RFDS mitigation to use X86_FEATURE_RFDS_CLEAR x86/cpu/intel: Add implicit RFDS mitigation for Goldmont and Tremont-D arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/bugs.c | 12 +++++------- arch/x86/kernel/cpu/intel.c | 14 ++++++++++++++ 3 files changed, 20 insertions(+), 7 deletions(-) -- 2.52.0
The current RFDS mitigation logic relies on verw_clears_cpu_reg_file(),
which directly checks the RFDS_CLEAR bit in the IA32_ARCH_CAPABILITIES MSR.
To support quirks for CPUs that mitigate RFDS but do not enumerate it,
transition to using the synthetic feature flag X86_FEATURE_RFDS_CLEAR.
Replace the MSR-bit-based check with boot_cpu_has(X86_FEATURE_RFDS_CLEAR)
and synthesize this feature bit in rfds_select_mitigation() if the
architectural RFDS_CLEAR bit is present.
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/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/bugs.c | 12 +++++-------
2 files changed, 6 insertions(+), 7 deletions(-)
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..479702bc9c00 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -648,11 +648,6 @@ static const char * const rfds_strings[] = {
[RFDS_MITIGATION_UCODE_NEEDED] = "Vulnerable: No microcode",
};
-static inline bool __init verw_clears_cpu_reg_file(void)
-{
- return (x86_arch_cap_msr & ARCH_CAP_RFDS_CLEAR);
-}
-
static void __init rfds_select_mitigation(void)
{
if (!boot_cpu_has_bug(X86_BUG_RFDS)) {
@@ -670,7 +665,10 @@ static void __init rfds_select_mitigation(void)
if (rfds_mitigation == RFDS_MITIGATION_OFF)
return;
- if (verw_clears_cpu_reg_file())
+ if (x86_arch_cap_msr & ARCH_CAP_RFDS_CLEAR)
+ setup_force_cpu_cap(X86_FEATURE_RFDS_CLEAR);
+
+ if (boot_cpu_has(X86_FEATURE_RFDS_CLEAR))
verw_clear_cpu_buf_mitigation_selected = true;
}
@@ -683,7 +681,7 @@ static void __init rfds_update_mitigation(void)
rfds_mitigation = RFDS_MITIGATION_VERW;
if (rfds_mitigation == RFDS_MITIGATION_VERW) {
- if (!verw_clears_cpu_reg_file())
+ if (!boot_cpu_has(X86_FEATURE_RFDS_CLEAR))
rfds_mitigation = RFDS_MITIGATION_UCODE_NEEDED;
}
--
2.52.0On Fri, Jan 30, 2026 at 09:33:39PM +0900, Joongsun Moon-Lee wrote:
> The current RFDS mitigation logic relies on verw_clears_cpu_reg_file(),
> which directly checks the RFDS_CLEAR bit in the IA32_ARCH_CAPABILITIES MSR.
>
> To support quirks for CPUs that mitigate RFDS but do not enumerate it,
> transition to using the synthetic feature flag X86_FEATURE_RFDS_CLEAR.
>
> Replace the MSR-bit-based check with boot_cpu_has(X86_FEATURE_RFDS_CLEAR)
> and synthesize this feature bit in rfds_select_mitigation() if the
> architectural RFDS_CLEAR bit is present.
Please do not explain the diff - talk about why this patch exists and other
details which are not obvious from the code.
> @@ -670,7 +665,10 @@ static void __init rfds_select_mitigation(void)
> if (rfds_mitigation == RFDS_MITIGATION_OFF)
> return;
>
> - if (verw_clears_cpu_reg_file())
> + if (x86_arch_cap_msr & ARCH_CAP_RFDS_CLEAR)
> + setup_force_cpu_cap(X86_FEATURE_RFDS_CLEAR);
> +
> + if (boot_cpu_has(X86_FEATURE_RFDS_CLEAR))
> verw_clear_cpu_buf_mitigation_selected = true;
> }
So:
if (x86_arch_cap_msr & ARCH_CAP_RFDS_CLEAR) {
setup_force_cpu_cap(X86_FEATURE_RFDS_CLEAR);
verw_clear_cpu_buf_mitigation_selected = true;
}
?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
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.0On 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
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);
© 2016 - 2026 Red Hat, Inc.