From: Amit Shah <amit.shah@xxxxxxx>
Remove explicit RET stuffing / filling on VMEXITs and context
switches on AMD CPUs with the ERAPS feature (Zen5+).
With the Enhanced Return Address Prediction Security feature, any of
the following conditions triggers a flush of the RSB (aka RAP in AMD
manuals) in hardware:
* context switch (e.g., move to CR3)
* TLB flush
* some writes to CR4
The feature also explicitly tags host and guest addresses in the RSB -
eliminating the need for explicit flushing of the RSB on VMEXIT.
[RFC note: We'll wait for the APM to be updated with the real wording,
but assuming it's going to say the ERAPS feature works the way described
above, let's continue the discussion re: when the kernel currently calls
FILL_RETURN_BUFFER, and what dropping it entirely means.
Dave Hansen pointed out __switch_to_asm fills the RSB each time it's
called, so let's address the cases there:
1. user->kernel switch: Switching from userspace to kernelspace, and
then using user-stuffed RSB entries in the kernel is not possible
thanks to SMEP. We can safely drop the FILL_RETURN_BUFFER call for
this case. In fact, this is how the original code was when dwmw2
added it originally in c995efd5a. So while this case currently
triggers an RSB flush (and will not after this ERAPS patch), the
current flush isn't necessary for AMD systems with SMEP anyway.
2. user->user or kernel->kernel: If a user->user switch does not result
in a CR3 change, it's a different thread in the same process context.
That's the same case for kernel->kernel switch. In this case, the
RSB entries are still valid in that context, just not the correct
ones in the new thread's context. It's difficult to imagine this
being a security risk. The current code clearing it, and this patch
not doing so for AMD-with-ERAPS, isn't a concern as far as I see.
]
Feature mentioned in AMD PPR 57238. Will be resubmitted once APM is
public - which I'm told is imminent.
Signed-off-by: Amit Shah <amit.shah@xxxxxxx>
---
Documentation/admin-guide/hw-vuln/spectre.rst | 5 ++--
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/nospec-branch.h | 12 ++++++++
arch/x86/kernel/cpu/bugs.c | 29 ++++++++++++++-----
4 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst
index 132e0bc6007e..647c10c0307a 100644
--- a/Documentation/admin-guide/hw-vuln/spectre.rst
+++ b/Documentation/admin-guide/hw-vuln/spectre.rst
@@ -417,9 +417,10 @@ The possible values in this file are:
- Return stack buffer (RSB) protection status:
- ============= ===========================================
+ ============= ========================================================
'RSB filling' Protection of RSB on context switch enabled
- ============= ===========================================
+ 'ERAPS' Hardware RSB flush on context switches + guest/host tags
+ ============= ========================================================
- EIBRS Post-barrier Return Stack Buffer (PBRSB) protection status:
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 913fd3a7bac6..665032b12871 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -458,6 +458,7 @@
#define X86_FEATURE_AUTOIBRS (20*32+ 8) /* Automatic IBRS */
#define X86_FEATURE_NO_SMM_CTL_MSR (20*32+ 9) /* SMM_CTL MSR is not present */
+#define X86_FEATURE_ERAPS (20*32+24) /* Enhanced RAP / RSB / RAS Security */
#define X86_FEATURE_SBPB (20*32+27) /* Selective Branch Prediction Barrier */
#define X86_FEATURE_IBPB_BRTYPE (20*32+28) /* MSR_PRED_CMD[IBPB] flushes all branch type predictions */
#define X86_FEATURE_SRSO_NO (20*32+29) /* CPU is not affected by SRSO */
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 96b410b1d4e8..f5ee7fc71db5 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -117,6 +117,18 @@
* We define a CPP macro such that it can be used from both .S files and
* inline assembly. It's possible to do a .macro and then include that
* from C via asm(".include <asm/nospec-branch.h>") but let's not go there.
+ *
+ * AMD CPUs with the ERAPS feature may have a larger default RSB. These CPUs
+ * use the default number of entries on a host, and can optionally (based on
+ * hypervisor setup) use 32 (old) or the new default in a guest. The number
+ * of default entries is reflected in CPUID 8000_0021:EBX[23:16].
+ *
+ * With the ERAPS feature, RSB filling is not necessary anymore: the RSB is
+ * auto-cleared by hardware on context switches, TLB flushes, or some CR4
+ * writes. Adapting the value of RSB_CLEAR_LOOPS below for ERAPS would change
+ * it to a runtime variable instead of the current compile-time constant, so
+ * leave it as-is, as this works for both older CPUs, as well as newer ones
+ * with ERAPS.
*/
#define RETPOLINE_THUNK_SIZE 32
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 0aa629b5537d..02446815b0de 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1818,9 +1818,12 @@ static void __init spectre_v2_select_mitigation(void)
pr_info("%s\n", spectre_v2_strings[mode]);
/*
- * If Spectre v2 protection has been enabled, fill the RSB during a
- * context switch. In general there are two types of RSB attacks
- * across context switches, for which the CALLs/RETs may be unbalanced.
+ * If Spectre v2 protection has been enabled, the RSB needs to be
+ * cleared during a context switch. Either do it in software by
+ * filling the RSB, or in hardware via ERAPS.
+ *
+ * In general there are two types of RSB attacks across context
+ * switches, for which the CALLs/RETs may be unbalanced.
*
* 1) RSB underflow
*
@@ -1848,12 +1851,21 @@ static void __init spectre_v2_select_mitigation(void)
* RSB clearing.
*
* So to mitigate all cases, unconditionally fill RSB on context
- * switches.
+ * switches when ERAPS is not present.
*/
- setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
- pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch\n");
+ if (!boot_cpu_has(X86_FEATURE_ERAPS)) {
+ setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+ pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch\n");
- spectre_v2_determine_rsb_fill_type_at_vmexit(mode);
+ /*
+ * For guest -> host (or vice versa) RSB poisoning scenarios,
+ * determine the mitigation mode here. With ERAPS, RSB
+ * entries are tagged as host or guest - ensuring that neither
+ * the host nor the guest have to clear or fill RSB entries to
+ * avoid poisoning: skip RSB filling at VMEXIT in that case.
+ */
+ spectre_v2_determine_rsb_fill_type_at_vmexit(mode);
+ }
/*
* Retpoline protects the kernel, but doesn't protect firmware. IBRS
@@ -2866,7 +2878,7 @@ static ssize_t spectre_v2_show_state(char *buf)
spectre_v2_enabled == SPECTRE_V2_EIBRS_LFENCE)
return sysfs_emit(buf, "Vulnerable: eIBRS+LFENCE with unprivileged eBPF and SMT\n");
- return sysfs_emit(buf, "%s%s%s%s%s%s%s%s\n",
+ return sysfs_emit(buf, "%s%s%s%s%s%s%s%s%s\n",
spectre_v2_strings[spectre_v2_enabled],
ibpb_state(),
boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? "; IBRS_FW" : "",
@@ -2874,6 +2886,7 @@ static ssize_t spectre_v2_show_state(char *buf)
boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? "; RSB filling" : "",
pbrsb_eibrs_state(),
spectre_bhi_state(),
+ boot_cpu_has(X86_FEATURE_ERAPS) ? "; ERAPS hardware RSB flush" : "",
/* this should always be at the end */
spectre_v2_module_string());
}
--
2.47.0
