Skip to contentSkip to conversation

x86/bugs: RSB tweaks

PATCH Superseded Josh Poimboeuf 3 participants 10 messages Nov 20, 2024 – Nov 21, 2024

Subsystems (4)
x86 KVM x86 MM x86 hardware vulnerabilities

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Josh Poimboeuf

author maintainer
#0 lore raw

cover x86/bugs: RSB tweaks

Some RSB filling tweaks as discussed in the following thread:

[RFC PATCH v2 0/3] Add support for the ERAPS feature
https://lore.kernel.org/[email protected]

Josh Poimboeuf (2):
x86/bugs: Don't fill RSB on VMEXIT with eIBRS+retpoline x86/bugs: Don't fill RSB on context switch with eIBRS

 arch/x86/kernel/cpu/bugs.c | 97 +++++++++++++++-----------------------
 arch/x86/mm/tlb.c          |  2 +-
 2 files changed, 38 insertions(+), 61 deletions(-)
Signature · 1 line
2.47.0
author maintainer
#1 lore raw

PATCH 1/2 x86/bugs: Don't fill RSB on VMEXIT with eIBRS+retpoline

eIBRS protects against RSB underflow/poisoning attacks. Adding retpoline to the mix doesn't change that. Retpoline has a balanced CALL/RET anyway.

So the current full RSB filling on VMEXIT with eIBRS+retpoline is overkill. Disable it (or do the VMEXIT_LITE mitigation if needed).

Suggested-by Pawan Gupta <[email protected]>
Signed-off-by Josh Poimboeuf <[email protected]>
---
 arch/x86/kernel/cpu/bugs.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
arch/x86/kernel/cpu/bugs.c +4 -4
index 47a01d4028f6..68bed17f0980 100644
@@ -1605,20 +1605,20 @@ static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_
 	case SPECTRE_V2_NONE:
 		return;
 
-	case SPECTRE_V2_EIBRS_LFENCE:
 	case SPECTRE_V2_EIBRS:
+	case SPECTRE_V2_EIBRS_LFENCE:
+	case SPECTRE_V2_EIBRS_RETPOLINE:
 		if (boot_cpu_has_bug(X86_BUG_EIBRS_PBRSB)) {
-			setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT_LITE);
 			pr_info("Spectre v2 / PBRSB-eIBRS: Retire a single CALL on VMEXIT\n");
+			setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT_LITE);
 		}
 		return;
 
-	case SPECTRE_V2_EIBRS_RETPOLINE:
 	case SPECTRE_V2_RETPOLINE:
 	case SPECTRE_V2_LFENCE:
 	case SPECTRE_V2_IBRS:
-		setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT);
 		pr_info("Spectre v2 / SpectreRSB : Filling RSB on VMEXIT\n");
+		setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT);
 		return;
 	}
Signature · 1 line
2.47.0
reviewer Reviewed-by on v1 1/2
#2 lore raw

Re: [PATCH 1/2] x86/bugs: Don't fill RSB on VMEXIT with eIBRS+retpoline

Quoted 9 lines · Josh Poimboeuf

eIBRS protects against RSB underflow/poisoning attacks. Adding retpoline to the mix doesn't change that. Retpoline has a balanced CALL/RET anyway.

So the current full RSB filling on VMEXIT with eIBRS+retpoline is overkill. Disable it (or do the VMEXIT_LITE mitigation if needed).

Suggested-by Pawan Gupta <[email protected]>
Signed-off-by Josh Poimboeuf <[email protected]>
Reviewed-by Pawan Gupta <[email protected]>
author maintainer
#3 lore raw

PATCH 2/2 x86/bugs: Don't fill RSB on context switch with eIBRS

In reply to Josh Poimboeuf

User->user Spectre v2 attacks (including RSB) across context switches are already mitigated by IBPB in cond_mitigation(), if enabled globally or if at least one of the tasks 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. Fix that.

While at it, update and coalesce the comments describing the various RSB mitigations.

Suggested-by Pawan Gupta <[email protected]>
Signed-off-by Josh Poimboeuf <[email protected]>
---
 arch/x86/kernel/cpu/bugs.c | 91 ++++++++++++++------------------------
 arch/x86/mm/tlb.c          |  2 +-
 2 files changed, 35 insertions(+), 58 deletions(-)
arch/x86/kernel/cpu/bugs.c +34 -57
index 68bed17f0980..e261f41749b0 100644
@@ -1579,27 +1579,44 @@ 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:

@@ -1617,12 +1634,13 @@ static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_
 	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;
 	}
 
-	pr_warn_once("Unknown Spectre v2 mode, disabling RSB mitigation at VM exit");
+	pr_warn_once("Unknown Spectre v2 mode, disabling RSB mitigation\n");
 	dump_stack();
 }
 

@@ -1817,48 +1835,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
arch/x86/mm/tlb.c +1 -1
index 86593d1b787d..c693b877d4df 100644
@@ -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.
 	 *
Signature · 1 line
2.47.0
#4 lore raw

Re: [PATCH 2/2] x86/bugs: Don't fill RSB on context switch with eIBRS

Quoted 8 lines · Josh Poimboeuf

User->user Spectre v2 attacks (including RSB) across context switches are already mitigated by IBPB in cond_mitigation(), if enabled globally
or if at least one of the tasks has opted in to protection.  RSB filling
without IBPB serves no purpose for protecting user space, as indirect branches are still vulnerable.

Quoted 7 lines

User->kernel RSB attacks are mitigated by eIBRS.  In which case the RSB
filling on context switch isn't needed.  Fix that.

While at it, update and coalesce the comments describing the various RSB
mitigations.

Looks good from first impressions - but there's something that needs some deeper analysis: AMD's Automatic IBRS piggybacks on eIBRS, and has some special cases. Adding Kim to CC to check and confirm if everything's still as expected.

(cf commits
e7862eda309 x86/cpu: Support AMD Automatic IBRS
fd470a8beed x86/cpu: Enable STIBP on AMD if Automatic IBRS is enabled acaa4b5c4c8 x86/speculation: Do not enable Automatic IBRS if SEV-SNP is enabled
)

Amit

Quoted 202 lines
Suggested-by Pawan Gupta <[email protected]>
Signed-off-by Josh Poimboeuf <[email protected]>

---
 arch/x86/kernel/cpu/bugs.c | 91 ++++++++++++++---------------------- --
 arch/x86/mm/tlb.c          |  2 +-

 2 files changed, 35 insertions(+), 58 deletions(-)
arch/x86/kernel/cpu/bugs.c +0 -0
index 68bed17f0980..e261f41749b0 100644
@@ -1579,27 +1579,44 @@ 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)
 {
  /*

arch/x86/kernel/cpu/bugs.c +0 -1
-	 * Similar to context switches, there are two types of RSB

attacks

arch/x86/kernel/cpu/bugs.c +1 -1
-	 * after VM exit:
+	 * In general there are two types of RSB attacks:

  *

arch/x86/kernel/cpu/bugs.c +3 -1
-	 * 1) RSB underflow
+	 * 1) RSB underflow ("Intel Retbleed")
+	 *
+	 *    Some Intel parts have "bottomless RSB".  When the RSB

is empty,

arch/x86/kernel/cpu/bugs.c +1 -0
+	 *    speculated return targets may come from the branch

predictor,

arch/x86/kernel/cpu/bugs.c +3 -0
+	 *    which could have a user-poisoned BTB or BHB entry.
+	 *
+	 *    user->user attacks are mitigated by IBPB on context

switch.

arch/x86/kernel/cpu/bugs.c +2 -0
+	 *
+	 *    user->kernel attacks via context switch are mitigated

by IBRS,

arch/x86/kernel/cpu/bugs.c +3 -0
+	 *    eIBRS, or RSB filling.
+	 *
+	 *    user->kernel attacks via kernel entry are mitigated by

IBRS,

arch/x86/kernel/cpu/bugs.c +3 -0
+	 *    eIBRS, or call depth tracking.
+	 *
+	 *    On VMEXIT, guest->host attacks are mitigated by IBRS,

eIBRS, or

arch/x86/kernel/cpu/bugs.c +1 -0
+	 *    RSB filling.

  *
  * 2) Poisoned RSB entry
  *

arch/x86/kernel/cpu/bugs.c +0 -1
-	 * When retpoline is enabled, both are mitigated by

filling/clearing

arch/x86/kernel/cpu/bugs.c +1 -1
-	 * the RSB.
+	 *    On a context switch, the previous task can poison RSB

entries

arch/x86/kernel/cpu/bugs.c +1 -0
+	 *    used by the next task, controlling its speculative

return

arch/x86/kernel/cpu/bugs.c +1 -0
+	 *    targets.  Poisoned RSB entries can also be created by

"AMD

arch/x86/kernel/cpu/bugs.c +1 -0
+	 *    Retbleed" or SRSO.

  *

arch/x86/kernel/cpu/bugs.c +0 -1
-	 * When IBRS is enabled, while #1 would be mitigated by the

IBRS branch

arch/x86/kernel/cpu/bugs.c +0 -1
-	 * prediction isolation protections, RSB still needs to be

cleared

arch/x86/kernel/cpu/bugs.c +0 -1
-	 * because of #2.  Note that SMEP provides no protection

here, unlike

arch/x86/kernel/cpu/bugs.c +1 -1
-	 * user-space-poisoned RSB entries.
+	 *    user->user attacks are mitigated by IBPB on context

switch.
  *

arch/x86/kernel/cpu/bugs.c +0 -1
-	 * eIBRS should protect against RSB poisoning, but if the

EIBRS_PBRSB

arch/x86/kernel/cpu/bugs.c +0 -1
-	 * bug is present then a LITE version of RSB protection is

required,

arch/x86/kernel/cpu/bugs.c +0 -1
-	 * just a single call needs to retire before a RET is

executed.

arch/x86/kernel/cpu/bugs.c +1 -0
+	 *    user->kernel attacks via context switch are prevented

by

arch/x86/kernel/cpu/bugs.c +3 -0
+	 *    SMEP+eIBRS+SRSO mitigations, or RSB clearing.
+	 *
+	 *    guest->host attacks are mitigated by eIBRS or RSB

clearing on

arch/x86/kernel/cpu/bugs.c +1 -0
+	 *    VMEXIT.  eIBRS implementations with

X86_BUG_EIBRS_PBRSB still

arch/x86/kernel/cpu/bugs.c +1 -0
+	 *    need "lite" RSB filling which retires a CALL before

the first

arch/x86/kernel/cpu/bugs.c +1 -0
+	 *    RET.

  */
  switch (mode) {
  case SPECTRE_V2_NONE:

arch/x86/kernel/cpu/bugs.c +0 -0
@@ -1617,12 +1634,13 @@ static void __init

spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_ case SPECTRE_V2_RETPOLINE:
  case SPECTRE_V2_LFENCE:
  case SPECTRE_V2_IBRS:

arch/x86/kernel/cpu/bugs.c +0 -1
-		pr_info("Spectre v2 / SpectreRSB : Filling RSB on

VMEXIT\n");

arch/x86/kernel/cpu/bugs.c +1 -0
+		pr_info("Spectre v2 / SpectreRSB : Filling RSB on

context switch and VMEXIT\n");

arch/x86/kernel/cpu/bugs.c +1 -0
+		setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);

  setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT); return;
  }

arch/x86/kernel/cpu/bugs.c +0 -1
-	pr_warn_once("Unknown Spectre v2 mode, disabling RSB

mitigation at VM exit");

arch/x86/kernel/cpu/bugs.c +1 -0
+	pr_warn_once("Unknown Spectre v2 mode, disabling RSB

mitigation\n");
  dump_stack();
 }

arch/x86/kernel/cpu/bugs.c +0 -0
@@ -1817,48 +1835,7 @@ static void __init
 spectre_v2_select_mitigation(void)
  	spectre_v2_enabled = mode;
  	pr_info("%s\n", spectre_v2_strings[mode]);

arch/x86/kernel/cpu/bugs.c +0 -2
-	/*
-	 * If Spectre v2 protection has been enabled, fill the RSB

during a

arch/x86/kernel/cpu/bugs.c +0 -1
-	 * context switch.  In general there are two types of RSB

attacks

arch/x86/kernel/cpu/bugs.c +0 -1
-	 * across context switches, for which the CALLs/RETs may be

unbalanced.

arch/x86/kernel/cpu/bugs.c +0 -4
-	 *
-	 * 1) RSB underflow
-	 *
-	 *    Some Intel parts have "bottomless RSB".  When the RSB

is empty,

arch/x86/kernel/cpu/bugs.c +0 -1
-	 *    speculated return targets may come from the branch

predictor,

arch/x86/kernel/cpu/bugs.c +0 -3
-	 *    which could have a user-poisoned BTB or BHB entry.
-	 *
-	 *    AMD has it even worse: *all* returns are speculated

from the BTB,

arch/x86/kernel/cpu/bugs.c +0 -3
-	 *    regardless of the state of the RSB.
-	 *
-	 *    When IBRS or eIBRS is enabled, the "user -> kernel"

attack

arch/x86/kernel/cpu/bugs.c +0 -1
-	 *    scenario is mitigated by the IBRS branch prediction

isolation

arch/x86/kernel/cpu/bugs.c +0 -1
-	 *    properties, so the RSB buffer filling wouldn't be

necessary to

arch/x86/kernel/cpu/bugs.c +0 -3
-	 *    protect against this type of attack.
-	 *
-	 *    The "user -> user" attack scenario is mitigated by RSB

filling.

arch/x86/kernel/cpu/bugs.c +0 -4
-	 *
-	 * 2) Poisoned RSB entry
-	 *
-	 *    If the 'next' in-kernel return stack is shorter than

'prev',

arch/x86/kernel/cpu/bugs.c +0 -1
-	 *    'next' could be tricked into speculating with a user-

poisoned RSB

arch/x86/kernel/cpu/bugs.c +0 -3
-	 *    entry.
-	 *
-	 *    The "user -> kernel" attack scenario is mitigated by

SMEP and

arch/x86/kernel/cpu/bugs.c +0 -3
-	 *    eIBRS.
-	 *
-	 *    The "user -> user" scenario, also known as SpectreBHB,

requires

arch/x86/kernel/cpu/bugs.c +0 -3
-	 *    RSB clearing.
-	 *
-	 * So to mitigate all cases, unconditionally fill RSB on

context

arch/x86/kernel/cpu/bugs.c +0 -6
-	 * 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");

arch/x86/kernel/cpu/bugs.c +1 -2
-
-	spectre_v2_determine_rsb_fill_type_at_vmexit(mode);
+	spectre_v2_mitigate_rsb(mode);


  /*
  * Retpoline protects the kernel, but doesn't protect firmware.  IBRS

arch/x86/mm/tlb.c +0 -0
index 86593d1b787d..c693b877d4df 100644
@@ -388,7 +388,7 @@ static void cond_mitigation(struct task_struct
 *next)
  	prev_mm = this_cpu_read(cpu_tlbstate.last_user_mm_spec);


  /*

arch/x86/mm/tlb.c +0 -1
-	 * Avoid user/user BTB poisoning by flushing the branch

predictor

arch/x86/mm/tlb.c +1 -0
+	 * 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.
  *

author maintainer
#5 lore raw

Re: [PATCH 2/2] x86/bugs: Don't fill RSB on context switch with eIBRS

Quoted 13 lines · Amit
Quoted 12 lines · Josh Poimboeuf

User->user Spectre v2 attacks (including RSB) across context switches are already mitigated by IBPB in cond_mitigation(), if enabled globally
or if at least one of the tasks 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.  Fix that.

Quoted 8 lines
Quoted 3 lines

While at it, update and coalesce the comments describing the various RSB
mitigations.

Looks good from first impressions - but there's something that needs some deeper analysis: AMD's Automatic IBRS piggybacks on eIBRS, and has some special cases. Adding Kim to CC to check and confirm if everything's still as expected.

FWIW, so "Technical Guidance for Mitigating Branch Type Confusion" has the following:

Finally, branches that are predicted as ‘ret’ instructions get their predicted targets from the Return Address Predictor (RAP). AMD recommends software use a RAP stuffing sequence (mitigation V2-3 in [2]) and/or Supervisor Mode Execution Protection (SMEP) to ensure that the addresses in the RAP are safe for speculation. Collectively, we refer to these mitigations as “RAP Protection”.

So it sounds like user->kernel RAP poisoning is mitigated by SMEP on AMD.

Signature · 1 line
Josh
#6 lore raw

Re: [PATCH 2/2] x86/bugs: Don't fill RSB on context switch with eIBRS

Quoted 42 lines · On Wed, 2024-11-20 at 08:21 -0800, [email protected] wrote:
Quoted 21 lines · Amit
Quoted 15 lines · Josh Poimboeuf

User->user Spectre v2 attacks (including RSB) across context switches
are already mitigated by IBPB in cond_mitigation(), if enabled globally
or if at least one of the tasks 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.  Fix that.

Quoted 4 lines

While at it, update and coalesce the comments describing the various
RSB
mitigations.

Quoted 6 lines

Looks good from first impressions - but there's something that needs
some deeper analysis: AMD's Automatic IBRS piggybacks on eIBRS, and has
some special cases.  Adding Kim to CC to check and confirm if everything's still as expected.

FWIW, so "Technical Guidance for Mitigating Branch Type Confusion" has
the following:

  Finally, branches that are predicted as ‘ret’ instructions get their
  predicted targets from the Return Address Predictor (RAP). AMD recommends software use a RAP stuffing sequence (mitigation V2-3 in [2]) and/or Supervisor Mode Execution Protection (SMEP) to ensure that
  the addresses in the RAP are safe for speculation. Collectively, we refer to these mitigations as “RAP Protection”.

Quoted 2 lines

So it sounds like user->kernel RAP poisoning is mitigated by SMEP on AMD.

It indeed is. I'm just asking Kim to confirm whether the AutoIBRS workflow can be updated based on this rework -- esp with disabling it for SEV-SNP hosts. I just went through those patches, and it doesn't look like anything needs changing.

Amit

#7 lore raw

Re: [PATCH 2/2] x86/bugs: Don't fill RSB on context switch with eIBRS

In reply to Josh Poimboeuf

On Tue, 2024-11-19 at 23:27 -0800, Josh Poimboeuf wrote:

[...]

Quoted 9 lines
(quoted diff) +0 -0
@@ -1617,12 +1634,13 @@ static void __init

spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_ case SPECTRE_V2_RETPOLINE:
  case SPECTRE_V2_LFENCE:
  case SPECTRE_V2_IBRS:

(quoted diff) +0 -1
-		pr_info("Spectre v2 / SpectreRSB : Filling RSB on

VMEXIT\n");

(quoted diff) +1 -0
+		pr_info("Spectre v2 / SpectreRSB : Filling RSB on

context switch and VMEXIT\n");

Nit: stray whitespace before ':'

Quoted 10 lines
arch/x86/kernel/cpu/bugs.c +1 -0
+		setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);

  setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT); return;
  }

(quoted diff) +0 -1
-	pr_warn_once("Unknown Spectre v2 mode, disabling RSB

mitigation at VM exit");

(quoted diff) +1 -0
+	pr_warn_once("Unknown Spectre v2 mode, disabling RSB

mitigation\n");
  dump_stack();

For the ERAPS patches, they'll flow better if these two lines are within a 'default' switch statement (with the other returns changing to breaks). I can do that, of course, but if you need to spin a v2 and update that, it'll save some churn.

Thanks,

Amit

reviewer Reviewed-by on v1 2/2
#8 lore raw

Re: [PATCH 2/2] x86/bugs: Don't fill RSB on context switch with eIBRS

In reply to Josh Poimboeuf
Quoted 3 lines · Josh Poimboeuf

User->user Spectre v2 attacks (including RSB) across context switches are already mitigated by IBPB in cond_mitigation(), if enabled globally or if at least one of the tasks has opted in to protection. RSB filling

Is below less ambiguous?

s/if at least one of the tasks/if previous or the next task/

Quoted 11 lines

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. Fix that.

While at it, update and coalesce the comments describing the various RSB mitigations.

Suggested-by Pawan Gupta <[email protected]>
Signed-off-by Josh Poimboeuf <[email protected]>
Reviewed-by Pawan Gupta <[email protected]>