User->user Spectre v2 attacks (including RSB) across context switches
are already mitigated by IBPB in cond_mitigation(), if enabled globally
or if either the prev or the next task has opted in to protection. RSB
filling without IBPB serves no purpose for protecting user space, as
indirect branches are still vulnerable.
User->kernel RSB attacks are mitigated by eIBRS. In which case the RSB
filling on context switch isn't needed, so remove it.
While at it, update and coalesce the comments describing the various RSB
mitigations.
Suggested-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Reviewed-by: Amit Shah <amit.shah@amd.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
arch/x86/kernel/cpu/bugs.c | 103 +++++++++++++++----------------------
arch/x86/mm/tlb.c | 2 +-
2 files changed, 42 insertions(+), 63 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 68bed17f0980..d5102b72f74d 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1579,31 +1579,48 @@ static void __init spec_ctrl_disable_kernel_rrsba(void)
rrsba_disabled = true;
}
-static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_mitigation mode)
+static void __init spectre_v2_mitigate_rsb(enum spectre_v2_mitigation mode)
{
/*
- * Similar to context switches, there are two types of RSB attacks
- * after VM exit:
+ * In general there are two types of RSB attacks:
*
- * 1) RSB underflow
+ * 1) RSB underflow ("Intel Retbleed")
+ *
+ * Some Intel parts have "bottomless RSB". When the RSB is empty,
+ * speculated return targets may come from the branch predictor,
+ * which could have a user-poisoned BTB or BHB entry.
+ *
+ * user->user attacks are mitigated by IBPB on context switch.
+ *
+ * user->kernel attacks via context switch are mitigated by IBRS,
+ * eIBRS, or RSB filling.
+ *
+ * user->kernel attacks via kernel entry are mitigated by IBRS,
+ * eIBRS, or call depth tracking.
+ *
+ * On VMEXIT, guest->host attacks are mitigated by IBRS, eIBRS, or
+ * RSB filling.
*
* 2) Poisoned RSB entry
*
- * When retpoline is enabled, both are mitigated by filling/clearing
- * the RSB.
+ * On a context switch, the previous task can poison RSB entries
+ * used by the next task, controlling its speculative return
+ * targets. Poisoned RSB entries can also be created by "AMD
+ * Retbleed" or SRSO.
*
- * When IBRS is enabled, while #1 would be mitigated by the IBRS branch
- * prediction isolation protections, RSB still needs to be cleared
- * because of #2. Note that SMEP provides no protection here, unlike
- * user-space-poisoned RSB entries.
+ * user->user attacks are mitigated by IBPB on context switch.
*
- * eIBRS should protect against RSB poisoning, but if the EIBRS_PBRSB
- * bug is present then a LITE version of RSB protection is required,
- * just a single call needs to retire before a RET is executed.
+ * user->kernel attacks via context switch are prevented by
+ * SMEP+eIBRS+SRSO mitigations, or RSB clearing.
+ *
+ * guest->host attacks are mitigated by eIBRS or RSB clearing on
+ * VMEXIT. eIBRS implementations with X86_BUG_EIBRS_PBRSB still
+ * need "lite" RSB filling which retires a CALL before the first
+ * RET.
*/
switch (mode) {
case SPECTRE_V2_NONE:
- return;
+ break;
case SPECTRE_V2_EIBRS:
case SPECTRE_V2_EIBRS_LFENCE:
@@ -1612,18 +1629,21 @@ static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_
pr_info("Spectre v2 / PBRSB-eIBRS: Retire a single CALL on VMEXIT\n");
setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT_LITE);
}
- return;
+ break;
case SPECTRE_V2_RETPOLINE:
case SPECTRE_V2_LFENCE:
case SPECTRE_V2_IBRS:
- pr_info("Spectre v2 / SpectreRSB : Filling RSB on VMEXIT\n");
+ pr_info("Spectre v2 / SpectreRSB: Filling RSB on context switch and VMEXIT\n");
+ setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT);
- return;
- }
+ break;
- pr_warn_once("Unknown Spectre v2 mode, disabling RSB mitigation at VM exit");
- dump_stack();
+ default:
+ pr_warn_once("Unknown Spectre v2 mode, disabling RSB mitigation\n");
+ dump_stack();
+ break;
+ }
}
/*
@@ -1817,48 +1837,7 @@ static void __init spectre_v2_select_mitigation(void)
spectre_v2_enabled = mode;
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.
- *
- * 1) RSB underflow
- *
- * Some Intel parts have "bottomless RSB". When the RSB is empty,
- * speculated return targets may come from the branch predictor,
- * which could have a user-poisoned BTB or BHB entry.
- *
- * AMD has it even worse: *all* returns are speculated from the BTB,
- * regardless of the state of the RSB.
- *
- * When IBRS or eIBRS is enabled, the "user -> kernel" attack
- * scenario is mitigated by the IBRS branch prediction isolation
- * properties, so the RSB buffer filling wouldn't be necessary to
- * protect against this type of attack.
- *
- * The "user -> user" attack scenario is mitigated by RSB filling.
- *
- * 2) Poisoned RSB entry
- *
- * If the 'next' in-kernel return stack is shorter than 'prev',
- * 'next' could be tricked into speculating with a user-poisoned RSB
- * entry.
- *
- * The "user -> kernel" attack scenario is mitigated by SMEP and
- * eIBRS.
- *
- * The "user -> user" scenario, also known as SpectreBHB, requires
- * RSB clearing.
- *
- * So to mitigate all cases, unconditionally fill RSB on context
- * switches.
- *
- * FIXME: Is this pointless for retbleed-affected AMD?
- */
- 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);
+ spectre_v2_mitigate_rsb(mode);
/*
* Retpoline protects the kernel, but doesn't protect firmware. IBRS
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 86593d1b787d..dc388f5ae7ef 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -388,7 +388,7 @@ static void cond_mitigation(struct task_struct *next)
prev_mm = this_cpu_read(cpu_tlbstate.last_user_mm_spec);
/*
- * Avoid user/user BTB poisoning by flushing the branch predictor
+ * Avoid user->user BTB/RSB poisoning by flushing the branch predictor
* when switching between processes. This stops one process from
* doing Spectre-v2 attacks on another.
*
--
2.47.0On Thu, Nov 21, 2024 at 12:07:19PM -0800, Josh Poimboeuf wrote: > User->user Spectre v2 attacks (including RSB) across context switches > are already mitigated by IBPB in cond_mitigation(), if enabled globally > or if either the prev or the next task has opted in to protection. RSB > filling without IBPB serves no purpose for protecting user space, as > indirect branches are still vulnerable. Question for Intel/AMD folks: where is it documented that IBPB clears the RSB? I thought I'd seen this somewhere but I can't seem to find it. -- Josh
On Thu, 2024-12-05 at 15:32 -0800, Josh Poimboeuf wrote: > On Thu, Nov 21, 2024 at 12:07:19PM -0800, Josh Poimboeuf wrote: > > User->user Spectre v2 attacks (including RSB) across context > > switches > > are already mitigated by IBPB in cond_mitigation(), if enabled > > globally > > or if either the prev or the next task has opted in to protection. > > RSB > > filling without IBPB serves no purpose for protecting user space, > > as > > indirect branches are still vulnerable. > > Question for Intel/AMD folks: where is it documented that IBPB clears > the RSB? I thought I'd seen this somewhere but I can't seem to find > it. "AMD64 TECHNOLOGY INDIRECT BRANCH CONTROL EXTENSION" https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/white-papers/111006-architecture-guidelines-update-amd64-technology-indirect-branch-control-extension.pdf has: Indirect branch prediction barrier (IBPB) exists at MSR 0x49 (PRED_CMD) it 0. This is a write only MSR that both GP faults when software reads it or if software tries to write any of the bits in 63:1. When bit zero is written, the processor guarantees that older indirect branches cannot influence predictions of indirect branches in the future. This applies to jmp indirects, call indirects and returns. As this restricts the processor from using all previous indirect branch information, it is intended to only be used by software when switching from one user context to another user context that requires protection, or from one guest to another guest. Amit
On Fri, Dec 06, 2024 at 10:10:31AM +0000, Shah, Amit wrote: > On Thu, 2024-12-05 at 15:32 -0800, Josh Poimboeuf wrote: > > On Thu, Nov 21, 2024 at 12:07:19PM -0800, Josh Poimboeuf wrote: > > > User->user Spectre v2 attacks (including RSB) across context > > > switches > > > are already mitigated by IBPB in cond_mitigation(), if enabled > > > globally > > > or if either the prev or the next task has opted in to protection. > > > RSB > > > filling without IBPB serves no purpose for protecting user space, > > > as > > > indirect branches are still vulnerable. > > > > Question for Intel/AMD folks: where is it documented that IBPB clears > > the RSB? I thought I'd seen this somewhere but I can't seem to find > > it. > > "AMD64 TECHNOLOGY INDIRECT BRANCH CONTROL EXTENSION" > https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/white-papers/111006-architecture-guidelines-update-amd64-technology-indirect-branch-control-extension.pdf > > has: > > Indirect branch prediction barrier (IBPB) exists at MSR 0x49 (PRED_CMD) > it 0. This is a write only MSR that both GP faults when software reads > it or if software tries to write any of the bits in 63:1. When bit zero > is written, the processor guarantees that older indirect branches > cannot influence predictions of indirect branches in the future. This > applies to jmp indirects, call indirects and returns. As this restricts > the processor from using all previous indirect branch information, it > is intended to only be used by software when switching from one user > context to another user context that requires protection, or from one > guest to another guest. Sounds like that needs to be updated to mention the IBPB_RET bit. -- Josh
On Thu, Dec 05, 2024 at 03:32:47PM -0800, Josh Poimboeuf wrote: > On Thu, Nov 21, 2024 at 12:07:19PM -0800, Josh Poimboeuf wrote: > > User->user Spectre v2 attacks (including RSB) across context switches > > are already mitigated by IBPB in cond_mitigation(), if enabled globally > > or if either the prev or the next task has opted in to protection. RSB > > filling without IBPB serves no purpose for protecting user space, as > > indirect branches are still vulnerable. > > Question for Intel/AMD folks: where is it documented that IBPB clears > the RSB? I thought I'd seen this somewhere but I can't seem to find it. For Intel, I found this: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html "Software that executed before the IBPB command cannot control the predicted targets of indirect branches executed after the command on the same logical processor. The term indirect branch in this context includes near return instructions, so these predicted targets may come from the RSB. This article uses the term RSB-barrier to refer to either an IBPB command event, or (on processors which support enhanced IBRS) either a VM exit with IBRS set to 1 or setting IBRS to 1 after a VM exit." I haven't seen anything that explicit for AMD. -- Josh
On Thu, Dec 05, 2024 at 04:53:03PM -0800, Josh Poimboeuf wrote: > On Thu, Dec 05, 2024 at 03:32:47PM -0800, Josh Poimboeuf wrote: > > On Thu, Nov 21, 2024 at 12:07:19PM -0800, Josh Poimboeuf wrote: > > > User->user Spectre v2 attacks (including RSB) across context switches > > > are already mitigated by IBPB in cond_mitigation(), if enabled globally > > > or if either the prev or the next task has opted in to protection. RSB > > > filling without IBPB serves no purpose for protecting user space, as > > > indirect branches are still vulnerable. > > > > Question for Intel/AMD folks: where is it documented that IBPB clears > > the RSB? I thought I'd seen this somewhere but I can't seem to find it. > > For Intel, I found this: > > https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html > > "Software that executed before the IBPB command cannot control the > predicted targets of indirect branches executed after the command on > the same logical processor. The term indirect branch in this context > includes near return instructions, so these predicted targets may come > from the RSB. > > This article uses the term RSB-barrier to refer to either an IBPB > command event, or (on processors which support enhanced IBRS) either a > VM exit with IBRS set to 1 or setting IBRS to 1 after a VM exit." > > I haven't seen anything that explicit for AMD. Found it. As Andrew mentioned earlier, AMD IBPB only clears RSB if the IBPB_RET CPUID bit is set. From APM vol 3: CPUID Fn8000_0008_EBX Extended Feature Identifiers: 30 IBPB_RET The processor clears the return address predictor when MSR PRED_CMD.IBPB is written to 1. We check that already for the IBPB entry mitigation, but now we'll also need to do so for the context switch IBPB. Question for AMD, does SBPB behave the same way, i.e. does it clear RSB if IBPB_RET? -- Josh
On Fri, 2024-12-06 at 15:02 -0800, Josh Poimboeuf wrote: > On Thu, Dec 05, 2024 at 04:53:03PM -0800, Josh Poimboeuf wrote: > > On Thu, Dec 05, 2024 at 03:32:47PM -0800, Josh Poimboeuf wrote: > > > On Thu, Nov 21, 2024 at 12:07:19PM -0800, Josh Poimboeuf wrote: > > > > User->user Spectre v2 attacks (including RSB) across context > > > > switches > > > > are already mitigated by IBPB in cond_mitigation(), if enabled > > > > globally > > > > or if either the prev or the next task has opted in to > > > > protection. RSB > > > > filling without IBPB serves no purpose for protecting user > > > > space, as > > > > indirect branches are still vulnerable. > > > > > > Question for Intel/AMD folks: where is it documented that IBPB > > > clears > > > the RSB? I thought I'd seen this somewhere but I can't seem to > > > find it. > > > > For Intel, I found this: > > > > > > https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html > > > > "Software that executed before the IBPB command cannot control > > the > > predicted targets of indirect branches executed after the command > > on > > the same logical processor. The term indirect branch in this > > context > > includes near return instructions, so these predicted targets may > > come > > from the RSB. > > > > This article uses the term RSB-barrier to refer to either an IBPB > > command event, or (on processors which support enhanced IBRS) > > either a > > VM exit with IBRS set to 1 or setting IBRS to 1 after a VM exit." > > > > I haven't seen anything that explicit for AMD. > > Found it. As Andrew mentioned earlier, AMD IBPB only clears RSB if > the > IBPB_RET CPUID bit is set. From APM vol 3: > > CPUID Fn8000_0008_EBX Extended Feature Identifiers: > > 30 IBPB_RET The processor clears the return address > predictor when MSR PRED_CMD.IBPB is written > to 1. > > We check that already for the IBPB entry mitigation, but now we'll > also > need to do so for the context switch IBPB. > > Question for AMD, does SBPB behave the same way, i.e. does it clear > RSB > if IBPB_RET? That's correct - SBPB clears the RSB only when IBPB_RET is set. Amit
On Fri, 2024-12-06 at 15:02 -0800, Josh Poimboeuf wrote: > On Thu, Dec 05, 2024 at 04:53:03PM -0800, Josh Poimboeuf wrote: > > On Thu, Dec 05, 2024 at 03:32:47PM -0800, Josh Poimboeuf wrote: > > > On Thu, Nov 21, 2024 at 12:07:19PM -0800, Josh Poimboeuf wrote: > > > > User->user Spectre v2 attacks (including RSB) across context > > > > switches > > > > are already mitigated by IBPB in cond_mitigation(), if enabled > > > > globally > > > > or if either the prev or the next task has opted in to > > > > protection. RSB > > > > filling without IBPB serves no purpose for protecting user > > > > space, as > > > > indirect branches are still vulnerable. > > > > > > Question for Intel/AMD folks: where is it documented that IBPB > > > clears > > > the RSB? I thought I'd seen this somewhere but I can't seem to > > > find it. > > > > For Intel, I found this: > > > > > > https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html > > > > "Software that executed before the IBPB command cannot control > > the > > predicted targets of indirect branches executed after the command > > on > > the same logical processor. The term indirect branch in this > > context > > includes near return instructions, so these predicted targets may > > come > > from the RSB. > > > > This article uses the term RSB-barrier to refer to either an IBPB > > command event, or (on processors which support enhanced IBRS) > > either a > > VM exit with IBRS set to 1 or setting IBRS to 1 after a VM exit." > > > > I haven't seen anything that explicit for AMD. > > Found it. As Andrew mentioned earlier, AMD IBPB only clears RSB if > the > IBPB_RET CPUID bit is set. From APM vol 3: > > CPUID Fn8000_0008_EBX Extended Feature Identifiers: > > 30 IBPB_RET The processor clears the return address > predictor when MSR PRED_CMD.IBPB is written > to 1. > > We check that already for the IBPB entry mitigation, but now we'll > also > need to do so for the context switch IBPB. > > Question for AMD, does SBPB behave the same way, i.e. does it clear > RSB > if IBPB_RET? I'm not sure about this. I'll ask around internally. Amit
On Thu, Nov 21, 2024 at 12:07:19PM -0800, Josh Poimboeuf wrote:
> @@ -1579,31 +1579,48 @@ static void __init spec_ctrl_disable_kernel_rrsba(void)
> rrsba_disabled = true;
> }
>
> -static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_mitigation mode)
> +static void __init spectre_v2_mitigate_rsb(enum spectre_v2_mitigation mode)
mitigate the return stack buffer?
The previous name was describing better what this function does...
Perhaps
spectre_v2_determine_rsb_handling()
or so. "Handling" to mean, what do to with the RSB based on the selected
Spectre v2 mitigation.
> {
> /*
> - * Similar to context switches, there are two types of RSB attacks
> - * after VM exit:
> + * In general there are two types of RSB attacks:
> *
> - * 1) RSB underflow
> + * 1) RSB underflow ("Intel Retbleed")
> + *
> + * Some Intel parts have "bottomless RSB". When the RSB is empty,
This is exactly what I mean with expanding this in Documentation/: Which parts
are those?
> + * speculated return targets may come from the branch predictor,
> + * which could have a user-poisoned BTB or BHB entry.
Also there we could explain what those alternative predictors are:
"RSBA: The processor supports RSB Alternate. Alternative branch predictors may
be used by RET instructions when the RSB is empty."
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/speculative-execution-side-channel-mitigations.html
> + *
> + * user->user attacks are mitigated by IBPB on context switch.
> + *
> + * user->kernel attacks via context switch are mitigated by IBRS,
> + * eIBRS, or RSB filling.
> + *
> + * user->kernel attacks via kernel entry are mitigated by IBRS,
> + * eIBRS, or call depth tracking.
> + *
> + * On VMEXIT, guest->host attacks are mitigated by IBRS, eIBRS, or
> + * RSB filling.
I like the explanation of every attack vector. I'd like even more if that were
expanded in Documentation/ and we can always go look it up there when touching
this code or reviewing patches touching it.
> *
> * 2) Poisoned RSB entry
> *
> - * When retpoline is enabled, both are mitigated by filling/clearing
> - * the RSB.
> + * On a context switch, the previous task can poison RSB entries
> + * used by the next task, controlling its speculative return
> + * targets. Poisoned RSB entries can also be created by "AMD
> + * Retbleed" or SRSO.
"... by the AMD Retbleed variant... "
> *
> - * When IBRS is enabled, while #1 would be mitigated by the IBRS branch
> - * prediction isolation protections, RSB still needs to be cleared
> - * because of #2. Note that SMEP provides no protection here, unlike
> - * user-space-poisoned RSB entries.
> + * user->user attacks are mitigated by IBPB on context switch.
> *
> - * eIBRS should protect against RSB poisoning, but if the EIBRS_PBRSB
> - * bug is present then a LITE version of RSB protection is required,
> - * just a single call needs to retire before a RET is executed.
> + * user->kernel attacks via context switch are prevented by
> + * SMEP+eIBRS+SRSO mitigations, or RSB clearing.
we call it "RSB filling" above. What's the difference?
The hw *IBRS* vs our RSB stuffing sw sequence?
> + * guest->host attacks are mitigated by eIBRS or RSB clearing on
> + * VMEXIT.
I think you mean our sw RSB stuffing sequence here.
> eIBRS implementations with X86_BUG_EIBRS_PBRSB still
> + * need "lite" RSB filling which retires a CALL before the first
> + * RET.
> */
> switch (mode) {
> case SPECTRE_V2_NONE:
> - return;
> + break;
>
> case SPECTRE_V2_EIBRS:
> case SPECTRE_V2_EIBRS_LFENCE:
> @@ -1612,18 +1629,21 @@ static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_
> pr_info("Spectre v2 / PBRSB-eIBRS: Retire a single CALL on VMEXIT\n");
> setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT_LITE);
> }
> - return;
> + break;
>
> case SPECTRE_V2_RETPOLINE:
> case SPECTRE_V2_LFENCE:
> case SPECTRE_V2_IBRS:
> - pr_info("Spectre v2 / SpectreRSB : Filling RSB on VMEXIT\n");
> + pr_info("Spectre v2 / SpectreRSB: Filling RSB on context switch and VMEXIT\n");
> + setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
Aha, with "RSB filling" you mean our sw sequence.
It would be good to have those explained properly and have some text
establishing the terminology we're using.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
© 2016 - 2025 Red Hat, Inc.