IBPB mitigation for VMSCAPE is an overkill for CPUs that are only affected
by the BHI variant of VMSCAPE. On such CPUs, eIBRS already provides
indirect branch isolation between guest and host userspace. But, a guest
could still poison the branch history.
To mitigate that, use the recently added clear_bhb_long_loop() to isolate
the branch history between guest and userspace. Add cmdline option
'vmscape=on' that automatically selects the appropriate mitigation based
on the CPU.
Acked-by: David Kaplan <david.kaplan@amd.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
Documentation/admin-guide/hw-vuln/vmscape.rst | 8 ++++
Documentation/admin-guide/kernel-parameters.txt | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/entry-common.h | 12 +++---
arch/x86/include/asm/nospec-branch.h | 2 +-
arch/x86/kernel/cpu/bugs.c | 53 ++++++++++++++++++-------
arch/x86/kvm/x86.c | 5 ++-
7 files changed, 61 insertions(+), 24 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/vmscape.rst b/Documentation/admin-guide/hw-vuln/vmscape.rst
index d9b9a2b6c114c05a7325e5f3c9d42129339b870b..580f288ae8bfc601ff000d6d95d711bb9084459e 100644
--- a/Documentation/admin-guide/hw-vuln/vmscape.rst
+++ b/Documentation/admin-guide/hw-vuln/vmscape.rst
@@ -86,6 +86,10 @@ The possible values in this file are:
run a potentially malicious guest and issues an IBPB before the first
exit to userspace after VM-exit.
+ * 'Mitigation: Clear BHB before exit to userspace':
+
+ As above, conditional BHB clearing mitigation is enabled.
+
* 'Mitigation: IBPB on VMEXIT':
IBPB is issued on every VM-exit. This occurs when other mitigations like
@@ -108,3 +112,7 @@ The mitigation can be controlled via the ``vmscape=`` command line parameter:
Force vulnerability detection and mitigation even on processors that are
not known to be affected.
+
+ * ``vmscape=on``:
+
+ Choose the mitigation based on the VMSCAPE variant the CPU is affected by.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 6c42061ca20e581b5192b66c6f25aba38d4f8ff8..4b4711ced5e187495476b5365cd7b3df81db893b 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -8104,9 +8104,11 @@
off - disable the mitigation
ibpb - use Indirect Branch Prediction Barrier
- (IBPB) mitigation (default)
+ (IBPB) mitigation
force - force vulnerability detection even on
unaffected processors
+ on - (default) automatically select IBPB
+ or BHB clear mitigation based on CPU
vsyscall= [X86-64,EARLY]
Controls the behavior of vsyscalls (i.e. calls to
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 4091a776e37aaed67ca93b0a0cd23cc25dbc33d4..3d547c3eab4e3290de3eee8e89f21587fee34931 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -499,6 +499,7 @@
#define X86_FEATURE_IBPB_EXIT_TO_USER (21*32+14) /* Use IBPB on exit-to-userspace, see VMSCAPE bug */
#define X86_FEATURE_ABMC (21*32+15) /* Assignable Bandwidth Monitoring Counters */
#define X86_FEATURE_MSR_IMM (21*32+16) /* MSR immediate form instructions */
+#define X86_FEATURE_CLEAR_BHB_EXIT_TO_USER (21*32+17) /* Clear branch history on exit-to-userspace, see VMSCAPE bug */
/*
* BUG word(s)
diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
index ce3eb6d5fdf9f2dba59b7bad24afbfafc8c36918..b629e85c33aa7387042cce60040b8a493e3e6d46 100644
--- a/arch/x86/include/asm/entry-common.h
+++ b/arch/x86/include/asm/entry-common.h
@@ -94,11 +94,13 @@ static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs,
*/
choose_random_kstack_offset(rdtsc());
- /* Avoid unnecessary reads of 'x86_ibpb_exit_to_user' */
- if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) &&
- this_cpu_read(x86_ibpb_exit_to_user)) {
- indirect_branch_prediction_barrier();
- this_cpu_write(x86_ibpb_exit_to_user, false);
+ if (unlikely(this_cpu_read(x86_predictor_flush_exit_to_user))) {
+ if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
+ indirect_branch_prediction_barrier();
+ if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_EXIT_TO_USER))
+ clear_bhb_long_loop();
+
+ this_cpu_write(x86_predictor_flush_exit_to_user, false);
}
}
#define arch_exit_to_user_mode_prepare arch_exit_to_user_mode_prepare
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 49707e563bdf71bdd05d3827f10dd2b8ac6bca2c..745394be734f3c2b5640c9aef10156fe1d02636b 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -534,7 +534,7 @@ void alternative_msr_write(unsigned int msr, u64 val, unsigned int feature)
: "memory");
}
-DECLARE_PER_CPU(bool, x86_ibpb_exit_to_user);
+DECLARE_PER_CPU(bool, x86_predictor_flush_exit_to_user);
static inline void indirect_branch_prediction_barrier(void)
{
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index d7fa03bf51b4517c12cc68e7c441f7589a4983d1..592730201b6e50a6b1f381e4179a0e45560418cc 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -109,12 +109,11 @@ DEFINE_PER_CPU(u64, x86_spec_ctrl_current);
EXPORT_PER_CPU_SYMBOL_GPL(x86_spec_ctrl_current);
/*
- * Set when the CPU has run a potentially malicious guest. An IBPB will
- * be needed to before running userspace. That IBPB will flush the branch
- * predictor content.
+ * Set when the CPU has run a potentially malicious guest. Indicates that a
+ * branch predictor flush is needed before running userspace.
*/
-DEFINE_PER_CPU(bool, x86_ibpb_exit_to_user);
-EXPORT_PER_CPU_SYMBOL_GPL(x86_ibpb_exit_to_user);
+DEFINE_PER_CPU(bool, x86_predictor_flush_exit_to_user);
+EXPORT_PER_CPU_SYMBOL_GPL(x86_predictor_flush_exit_to_user);
u64 x86_pred_cmd __ro_after_init = PRED_CMD_IBPB;
@@ -3197,13 +3196,15 @@ enum vmscape_mitigations {
VMSCAPE_MITIGATION_AUTO,
VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER,
VMSCAPE_MITIGATION_IBPB_ON_VMEXIT,
+ VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER,
};
static const char * const vmscape_strings[] = {
- [VMSCAPE_MITIGATION_NONE] = "Vulnerable",
+ [VMSCAPE_MITIGATION_NONE] = "Vulnerable",
/* [VMSCAPE_MITIGATION_AUTO] */
- [VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER] = "Mitigation: IBPB before exit to userspace",
- [VMSCAPE_MITIGATION_IBPB_ON_VMEXIT] = "Mitigation: IBPB on VMEXIT",
+ [VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER] = "Mitigation: IBPB before exit to userspace",
+ [VMSCAPE_MITIGATION_IBPB_ON_VMEXIT] = "Mitigation: IBPB on VMEXIT",
+ [VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER] = "Mitigation: Clear BHB before exit to userspace",
};
static enum vmscape_mitigations vmscape_mitigation __ro_after_init =
@@ -3221,6 +3222,8 @@ static int __init vmscape_parse_cmdline(char *str)
} else if (!strcmp(str, "force")) {
setup_force_cpu_bug(X86_BUG_VMSCAPE);
vmscape_mitigation = VMSCAPE_MITIGATION_AUTO;
+ } else if (!strcmp(str, "on")) {
+ vmscape_mitigation = VMSCAPE_MITIGATION_AUTO;
} else {
pr_err("Ignoring unknown vmscape=%s option.\n", str);
}
@@ -3231,18 +3234,35 @@ early_param("vmscape", vmscape_parse_cmdline);
static void __init vmscape_select_mitigation(void)
{
- if (!boot_cpu_has_bug(X86_BUG_VMSCAPE) ||
- !boot_cpu_has(X86_FEATURE_IBPB)) {
+ if (!boot_cpu_has_bug(X86_BUG_VMSCAPE)) {
vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
return;
}
- if (vmscape_mitigation == VMSCAPE_MITIGATION_AUTO) {
- if (should_mitigate_vuln(X86_BUG_VMSCAPE))
- vmscape_mitigation = VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER;
- else
- vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
+ if (vmscape_mitigation == VMSCAPE_MITIGATION_AUTO &&
+ !should_mitigate_vuln(X86_BUG_VMSCAPE))
+ vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
+
+ if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER &&
+ !boot_cpu_has(X86_FEATURE_IBPB)) {
+ pr_err("IBPB not supported, switching to AUTO select\n");
+ vmscape_mitigation = VMSCAPE_MITIGATION_AUTO;
}
+
+ if (vmscape_mitigation != VMSCAPE_MITIGATION_AUTO)
+ return;
+
+ /*
+ * CPUs with BHI_CTRL(ADL and newer) can avoid the IBPB and use BHB
+ * clear sequence. These CPUs are only vulnerable to the BHI variant
+ * of the VMSCAPE attack and does not require an IBPB flush.
+ */
+ if (boot_cpu_has(X86_FEATURE_BHI_CTRL))
+ vmscape_mitigation = VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER;
+ else if (boot_cpu_has(X86_FEATURE_IBPB))
+ vmscape_mitigation = VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER;
+ else
+ vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
}
static void __init vmscape_update_mitigation(void)
@@ -3261,6 +3281,8 @@ static void __init vmscape_apply_mitigation(void)
{
if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER)
setup_force_cpu_cap(X86_FEATURE_IBPB_EXIT_TO_USER);
+ else if (vmscape_mitigation == VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER)
+ setup_force_cpu_cap(X86_FEATURE_CLEAR_BHB_EXIT_TO_USER);
}
#undef pr_fmt
@@ -3352,6 +3374,7 @@ void cpu_bugs_smt_update(void)
break;
case VMSCAPE_MITIGATION_IBPB_ON_VMEXIT:
case VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER:
+ case VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER:
/*
* Hypervisors can be attacked across-threads, warn for SMT when
* STIBP is not already enabled system-wide.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b4b5d2d0963467a81c7cc00575547619654295c6..0212de0ec2da153acb4218dc187dfcb87eae7115 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11397,8 +11397,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
* set for the CPU that actually ran the guest, and not the CPU that it
* may migrate to.
*/
- if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
- this_cpu_write(x86_ibpb_exit_to_user, true);
+ if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) ||
+ cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_EXIT_TO_USER))
+ this_cpu_write(x86_predictor_flush_exit_to_user, true);
/*
* Consume any pending interrupts, including the possible source of
--
2.34.1On 10/27/25 16:43, Pawan Gupta wrote:
> IBPB mitigation for VMSCAPE is an overkill for CPUs that are only affected
> by the BHI variant of VMSCAPE. On such CPUs, eIBRS already provides
> indirect branch isolation between guest and host userspace. But, a guest
> could still poison the branch history.
This is missing a wee bit of background about how branch history and
indirect branch prediction are involved in VMSCAPE.
> To mitigate that, use the recently added clear_bhb_long_loop() to isolate
> the branch history between guest and userspace. Add cmdline option
> 'vmscape=on' that automatically selects the appropriate mitigation based
> on the CPU.
Is "=on" the right thing here as opposed to "=auto"? What you have here
doesn't actually turn VMSCAPE mitigation on for 'vmscape=on'.
> Documentation/admin-guide/hw-vuln/vmscape.rst | 8 ++++
> Documentation/admin-guide/kernel-parameters.txt | 4 +-
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/include/asm/entry-common.h | 12 +++---
> arch/x86/include/asm/nospec-branch.h | 2 +-
> arch/x86/kernel/cpu/bugs.c | 53 ++++++++++++++++++-------
> arch/x86/kvm/x86.c | 5 ++-
> 7 files changed, 61 insertions(+), 24 deletions(-)
I think I'd rather this be three or four or five more patches.
The rename:
> -DECLARE_PER_CPU(bool, x86_ibpb_exit_to_user);
> +DECLARE_PER_CPU(bool, x86_predictor_flush_exit_to_user);
could be alone by itself.
So could the additional command-line override and its documentation.
(whatever it gets named).
...
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 4091a776e37aaed67ca93b0a0cd23cc25dbc33d4..3d547c3eab4e3290de3eee8e89f21587fee34931 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -499,6 +499,7 @@
> #define X86_FEATURE_IBPB_EXIT_TO_USER (21*32+14) /* Use IBPB on exit-to-userspace, see VMSCAPE bug */
> #define X86_FEATURE_ABMC (21*32+15) /* Assignable Bandwidth Monitoring Counters */
> #define X86_FEATURE_MSR_IMM (21*32+16) /* MSR immediate form instructions */
> +#define X86_FEATURE_CLEAR_BHB_EXIT_TO_USER (21*32+17) /* Clear branch history on exit-to-userspace, see VMSCAPE bug */
X86_FEATURE flags are cheap, but they're not infinite. Is this worth two
of these? It actually makes the code actively worse. (See below).
> diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
> index ce3eb6d5fdf9f2dba59b7bad24afbfafc8c36918..b629e85c33aa7387042cce60040b8a493e3e6d46 100644
> --- a/arch/x86/include/asm/entry-common.h
> +++ b/arch/x86/include/asm/entry-common.h
> @@ -94,11 +94,13 @@ static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs,
> */
> choose_random_kstack_offset(rdtsc());
>
> - /* Avoid unnecessary reads of 'x86_ibpb_exit_to_user' */
> - if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) &&
> - this_cpu_read(x86_ibpb_exit_to_user)) {
> - indirect_branch_prediction_barrier();
> - this_cpu_write(x86_ibpb_exit_to_user, false);
> + if (unlikely(this_cpu_read(x86_predictor_flush_exit_to_user))) {
> + if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
> + indirect_branch_prediction_barrier();
> + if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_EXIT_TO_USER))
> + clear_bhb_long_loop();
> +
> + this_cpu_write(x86_predictor_flush_exit_to_user, false);
> }
> }
One (mildly) nice thing about the old code was that it could avoid
reading 'x86_predictor_flush_exit_to_user' in the unaffected case.
Also, how does the code generation end up looking here? Each
cpu_feature_enabled() has an alternative, and
indirect_branch_prediction_barrier() has another one. Are we generating
alternatives that can't even possibly happen? For instance, could we
ever have system with X86_FEATURE_IBPB_EXIT_TO_USER but *not*
X86_FEATURE_IBPB?
Let's say this was:
if (cpu_feature_enabled(X86_FEATURE_FOO_EXIT_TO_USER) &&
this_cpu_read(x86_ibpb_exit_to_user)) {
static_call(clear_branch_history);
this_cpu_write(x86_ibpb_exit_to_user, false);
}
And the static_call() was assigned to either clear_bhb_long_loop() or
write_ibpb(). I suspect the code generation would be nicer and it would
eliminate one reason for having two X86_FEATUREs.
> static enum vmscape_mitigations vmscape_mitigation __ro_after_init =
> @@ -3221,6 +3222,8 @@ static int __init vmscape_parse_cmdline(char *str)
> } else if (!strcmp(str, "force")) {
> setup_force_cpu_bug(X86_BUG_VMSCAPE);
> vmscape_mitigation = VMSCAPE_MITIGATION_AUTO;
> + } else if (!strcmp(str, "on")) {
> + vmscape_mitigation = VMSCAPE_MITIGATION_AUTO;
> } else {
> pr_err("Ignoring unknown vmscape=%s option.\n", str);
> }
Yeah, it's goofy that =on sets ..._AUTO.
> @@ -3231,18 +3234,35 @@ early_param("vmscape", vmscape_parse_cmdline);
>
> static void __init vmscape_select_mitigation(void)
> {
> - if (!boot_cpu_has_bug(X86_BUG_VMSCAPE) ||
> - !boot_cpu_has(X86_FEATURE_IBPB)) {
> + if (!boot_cpu_has_bug(X86_BUG_VMSCAPE)) {
> vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
> return;
> }
>
> - if (vmscape_mitigation == VMSCAPE_MITIGATION_AUTO) {
> - if (should_mitigate_vuln(X86_BUG_VMSCAPE))
> - vmscape_mitigation = VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER;
> - else
> - vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
> + if (vmscape_mitigation == VMSCAPE_MITIGATION_AUTO &&
> + !should_mitigate_vuln(X86_BUG_VMSCAPE))
> + vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
> +
> + if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER &&
> + !boot_cpu_has(X86_FEATURE_IBPB)) {
> + pr_err("IBPB not supported, switching to AUTO select\n");
> + vmscape_mitigation = VMSCAPE_MITIGATION_AUTO;
> }
> +
> + if (vmscape_mitigation != VMSCAPE_MITIGATION_AUTO)
> + return;
> +
> + /*
> + * CPUs with BHI_CTRL(ADL and newer) can avoid the IBPB and use BHB
> + * clear sequence. These CPUs are only vulnerable to the BHI variant
> + * of the VMSCAPE attack and does not require an IBPB flush.
> + */
> + if (boot_cpu_has(X86_FEATURE_BHI_CTRL))
> + vmscape_mitigation = VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER;
> + else if (boot_cpu_has(X86_FEATURE_IBPB))
> + vmscape_mitigation = VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER;
> + else
> + vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
> }
Yeah, there are a *lot* of logic changes there. Any simplifications by
breaking this up would be appreciated.
> static void __init vmscape_update_mitigation(void)
> @@ -3261,6 +3281,8 @@ static void __init vmscape_apply_mitigation(void)
> {
> if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER)
> setup_force_cpu_cap(X86_FEATURE_IBPB_EXIT_TO_USER);
> + else if (vmscape_mitigation == VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER)
> + setup_force_cpu_cap(X86_FEATURE_CLEAR_BHB_EXIT_TO_USER);
> }
Yeah, so in that scheme I was talking about a minute ago, this could be
where you do a static_call_update() instead of setting individual
feature bits.
[ I drafted the reply this this email earlier, but forgot to send it, sorry. ]
On Mon, Nov 03, 2025 at 12:31:09PM -0800, Dave Hansen wrote:
> On 10/27/25 16:43, Pawan Gupta wrote:
> > IBPB mitigation for VMSCAPE is an overkill for CPUs that are only affected
> > by the BHI variant of VMSCAPE. On such CPUs, eIBRS already provides
> > indirect branch isolation between guest and host userspace. But, a guest
> > could still poison the branch history.
>
> This is missing a wee bit of background about how branch history and
> indirect branch prediction are involved in VMSCAPE.
Adding more background to this.
> > To mitigate that, use the recently added clear_bhb_long_loop() to isolate
> > the branch history between guest and userspace. Add cmdline option
> > 'vmscape=on' that automatically selects the appropriate mitigation based
> > on the CPU.
>
> Is "=on" the right thing here as opposed to "=auto"?
v1 had it as =auto, David Kaplan made a point that for attack vector controls
"auto" means "defer to attack vector controls":
https://lore.kernel.org/all/LV3PR12MB9265B1C6D9D36408539B68B9941EA@LV3PR12MB9265.namprd12.prod.outlook.com/
"Maybe a better solution instead is to add a new option 'vmscape=on'.
If we look at the other most recently added bugs like TSA and ITS, neither
have an explicit 'auto' cmdline option. But they do have 'on' cmdline
options.
The difference between 'auto' and 'on' is that 'auto' defers to the attack
vector controls while 'on' means 'enable this mitigation if the CPU is
vulnerable' (as opposed to 'force' which will enable it even if not
vulnerable).
An explicit 'vmscape=on' could give users an option to ensure the
mitigation is used (regardless of attack vectors) and could choose the best
mitigation (BHB clear if available, otherwise IBPB).
I'd still advise users to not specify any option here unless they know what
they're doing. But an 'on' option would arguably be more consistent with
the other recent bugs and maybe meets the needs you're after?"
> What you have here doesn't actually turn VMSCAPE mitigation on for
> 'vmscape=on'.
It picks between BHB-clear and IBPB, but it still turns 'on' the
mitigation. Maybe I am misunderstanding you?
> > Documentation/admin-guide/hw-vuln/vmscape.rst | 8 ++++
> > Documentation/admin-guide/kernel-parameters.txt | 4 +-
> > arch/x86/include/asm/cpufeatures.h | 1 +
> > arch/x86/include/asm/entry-common.h | 12 +++---
> > arch/x86/include/asm/nospec-branch.h | 2 +-
> > arch/x86/kernel/cpu/bugs.c | 53 ++++++++++++++++++-------
> > arch/x86/kvm/x86.c | 5 ++-
> > 7 files changed, 61 insertions(+), 24 deletions(-)
>
> I think I'd rather this be three or four or five more patches.
>
> The rename:
>
> > -DECLARE_PER_CPU(bool, x86_ibpb_exit_to_user);
> > +DECLARE_PER_CPU(bool, x86_predictor_flush_exit_to_user);
>
> could be alone by itself.
>
> So could the additional command-line override and its documentation.
> (whatever it gets named).
On it.
> > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> > index 4091a776e37aaed67ca93b0a0cd23cc25dbc33d4..3d547c3eab4e3290de3eee8e89f21587fee34931 100644
> > --- a/arch/x86/include/asm/cpufeatures.h
> > +++ b/arch/x86/include/asm/cpufeatures.h
> > @@ -499,6 +499,7 @@
> > #define X86_FEATURE_IBPB_EXIT_TO_USER (21*32+14) /* Use IBPB on exit-to-userspace, see VMSCAPE bug */
> > #define X86_FEATURE_ABMC (21*32+15) /* Assignable Bandwidth Monitoring Counters */
> > #define X86_FEATURE_MSR_IMM (21*32+16) /* MSR immediate form instructions */
> > +#define X86_FEATURE_CLEAR_BHB_EXIT_TO_USER (21*32+17) /* Clear branch history on exit-to-userspace, see VMSCAPE bug */
>
> X86_FEATURE flags are cheap, but they're not infinite. Is this worth two
> of these? It actually makes the code actively worse. (See below).
>
> > diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
> > index ce3eb6d5fdf9f2dba59b7bad24afbfafc8c36918..b629e85c33aa7387042cce60040b8a493e3e6d46 100644
> > --- a/arch/x86/include/asm/entry-common.h
> > +++ b/arch/x86/include/asm/entry-common.h
> > @@ -94,11 +94,13 @@ static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs,
> > */
> > choose_random_kstack_offset(rdtsc());
> >
> > - /* Avoid unnecessary reads of 'x86_ibpb_exit_to_user' */
> > - if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) &&
> > - this_cpu_read(x86_ibpb_exit_to_user)) {
> > - indirect_branch_prediction_barrier();
> > - this_cpu_write(x86_ibpb_exit_to_user, false);
> > + if (unlikely(this_cpu_read(x86_predictor_flush_exit_to_user))) {
> > + if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
> > + indirect_branch_prediction_barrier();
> > + if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_EXIT_TO_USER))
> > + clear_bhb_long_loop();
> > +
> > + this_cpu_write(x86_predictor_flush_exit_to_user, false);
> > }
> > }
>
> One (mildly) nice thing about the old code was that it could avoid
> reading 'x86_predictor_flush_exit_to_user' in the unaffected case.
Yes.
> Also, how does the code generation end up looking here? Each
> cpu_feature_enabled() has an alternative, and
> indirect_branch_prediction_barrier() has another one. Are we generating
> alternatives that can't even possibly happen? For instance, could we
> ever have system with X86_FEATURE_IBPB_EXIT_TO_USER but *not*
> X86_FEATURE_IBPB?
No, without IBPB X86_FEATURE_IBPB_EXIT_TO_USER won't be set. As you
suggested below, static_call() can call write_ibpb() directly in this case.
> Let's say this was:
>
> if (cpu_feature_enabled(X86_FEATURE_FOO_EXIT_TO_USER) &&
With static_call() we could also live without X86_FEATURE_FOO_EXIT_TO_USER,
but ...
> this_cpu_read(x86_ibpb_exit_to_user)) {
... it has a slight drawback that we read this always.
> static_call(clear_branch_history);
> this_cpu_write(x86_ibpb_exit_to_user, false);
> }
>
> And the static_call() was assigned to either clear_bhb_long_loop() or
> write_ibpb(). I suspect the code generation would be nicer and it would
> eliminate one reason for having two X86_FEATUREs.
Agree.
> > static enum vmscape_mitigations vmscape_mitigation __ro_after_init =
> > @@ -3221,6 +3222,8 @@ static int __init vmscape_parse_cmdline(char *str)
> > } else if (!strcmp(str, "force")) {
> > setup_force_cpu_bug(X86_BUG_VMSCAPE);
> > vmscape_mitigation = VMSCAPE_MITIGATION_AUTO;
> > + } else if (!strcmp(str, "on")) {
> > + vmscape_mitigation = VMSCAPE_MITIGATION_AUTO;
> > } else {
> > pr_err("Ignoring unknown vmscape=%s option.\n", str);
> > }
>
> Yeah, it's goofy that =on sets ..._AUTO.
Yes, we can go back to =auto. David, I hope it is not too big of a problem
with attack vector controls?
> > @@ -3231,18 +3234,35 @@ early_param("vmscape", vmscape_parse_cmdline);
> >
> > static void __init vmscape_select_mitigation(void)
> > {
> > - if (!boot_cpu_has_bug(X86_BUG_VMSCAPE) ||
> > - !boot_cpu_has(X86_FEATURE_IBPB)) {
> > + if (!boot_cpu_has_bug(X86_BUG_VMSCAPE)) {
> > vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
> > return;
> > }
> >
> > - if (vmscape_mitigation == VMSCAPE_MITIGATION_AUTO) {
> > - if (should_mitigate_vuln(X86_BUG_VMSCAPE))
> > - vmscape_mitigation = VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER;
> > - else
> > - vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
> > + if (vmscape_mitigation == VMSCAPE_MITIGATION_AUTO &&
> > + !should_mitigate_vuln(X86_BUG_VMSCAPE))
> > + vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
> > +
> > + if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER &&
> > + !boot_cpu_has(X86_FEATURE_IBPB)) {
> > + pr_err("IBPB not supported, switching to AUTO select\n");
> > + vmscape_mitigation = VMSCAPE_MITIGATION_AUTO;
> > }
> > +
> > + if (vmscape_mitigation != VMSCAPE_MITIGATION_AUTO)
> > + return;
> > +
> > + /*
> > + * CPUs with BHI_CTRL(ADL and newer) can avoid the IBPB and use BHB
> > + * clear sequence. These CPUs are only vulnerable to the BHI variant
> > + * of the VMSCAPE attack and does not require an IBPB flush.
> > + */
> > + if (boot_cpu_has(X86_FEATURE_BHI_CTRL))
> > + vmscape_mitigation = VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER;
> > + else if (boot_cpu_has(X86_FEATURE_IBPB))
> > + vmscape_mitigation = VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER;
> > + else
> > + vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
> > }
>
> Yeah, there are a *lot* of logic changes there. Any simplifications by
> breaking this up would be appreciated.
Into multiple patches, I guess? Will do.
> > static void __init vmscape_update_mitigation(void)
> > @@ -3261,6 +3281,8 @@ static void __init vmscape_apply_mitigation(void)
> > {
> > if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER)
> > setup_force_cpu_cap(X86_FEATURE_IBPB_EXIT_TO_USER);
> > + else if (vmscape_mitigation == VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER)
> > + setup_force_cpu_cap(X86_FEATURE_CLEAR_BHB_EXIT_TO_USER);
> > }
>
> Yeah, so in that scheme I was talking about a minute ago, this could be
> where you do a static_call_update() instead of setting individual
> feature bits.
Yes, and we can avoid both IBPB_EXIT_TO_USER and CLEAR_BHB_EXIT_TO_USER
feature flags.
On 11/7/25 01:40, Pawan Gupta wrote: > [ I drafted the reply this this email earlier, but forgot to send it, sorry. ] > > On Mon, Nov 03, 2025 at 12:31:09PM -0800, Dave Hansen wrote: >> On 10/27/25 16:43, Pawan Gupta wrote: >>> IBPB mitigation for VMSCAPE is an overkill for CPUs that are only affected >>> by the BHI variant of VMSCAPE. On such CPUs, eIBRS already provides >>> indirect branch isolation between guest and host userspace. But, a guest >>> could still poison the branch history. >> >> This is missing a wee bit of background about how branch history and >> indirect branch prediction are involved in VMSCAPE. > > Adding more background to this. > >>> To mitigate that, use the recently added clear_bhb_long_loop() to isolate >>> the branch history between guest and userspace. Add cmdline option >>> 'vmscape=on' that automatically selects the appropriate mitigation based >>> on the CPU. >> >> Is "=on" the right thing here as opposed to "=auto"? > > v1 had it as =auto, David Kaplan made a point that for attack vector controls > "auto" means "defer to attack vector controls": > > https://lore.kernel.org/all/LV3PR12MB9265B1C6D9D36408539B68B9941EA@LV3PR12MB9265.namprd12.prod.outlook.com/ > > "Maybe a better solution instead is to add a new option 'vmscape=on'. > > If we look at the other most recently added bugs like TSA and ITS, neither > have an explicit 'auto' cmdline option. But they do have 'on' cmdline > options. > > The difference between 'auto' and 'on' is that 'auto' defers to the attack > vector controls while 'on' means 'enable this mitigation if the CPU is > vulnerable' (as opposed to 'force' which will enable it even if not > vulnerable). > > An explicit 'vmscape=on' could give users an option to ensure the > mitigation is used (regardless of attack vectors) and could choose the best > mitigation (BHB clear if available, otherwise IBPB). I thought the whole idea of attack vectors was because the gazillion options for gazillion mitigation became untenable over time. Now, what you are saying is - on top of the simplification, let's add yet more options to override the attack vectors o_O. IMO, having 'force' is sufficient to cover scenarios where people really want this mitigation - either because they know better, or because they want to test something. Force also covers the "on" case, so let's leave it at "on" for attack vector support, and 'force' for everything else <snip>
On Wed, Nov 19, 2025 at 12:33:05PM +0200, Nikolay Borisov wrote: > > > On 11/7/25 01:40, Pawan Gupta wrote: > > [ I drafted the reply this this email earlier, but forgot to send it, sorry. ] > > > > On Mon, Nov 03, 2025 at 12:31:09PM -0800, Dave Hansen wrote: > > > On 10/27/25 16:43, Pawan Gupta wrote: > > > > IBPB mitigation for VMSCAPE is an overkill for CPUs that are only affected > > > > by the BHI variant of VMSCAPE. On such CPUs, eIBRS already provides > > > > indirect branch isolation between guest and host userspace. But, a guest > > > > could still poison the branch history. > > > > > > This is missing a wee bit of background about how branch history and > > > indirect branch prediction are involved in VMSCAPE. > > > > Adding more background to this. > > > > > > To mitigate that, use the recently added clear_bhb_long_loop() to isolate > > > > the branch history between guest and userspace. Add cmdline option > > > > 'vmscape=on' that automatically selects the appropriate mitigation based > > > > on the CPU. > > > > > > Is "=on" the right thing here as opposed to "=auto"? > > > > v1 had it as =auto, David Kaplan made a point that for attack vector controls > > "auto" means "defer to attack vector controls": > > > > https://lore.kernel.org/all/LV3PR12MB9265B1C6D9D36408539B68B9941EA@LV3PR12MB9265.namprd12.prod.outlook.com/ > > > > "Maybe a better solution instead is to add a new option 'vmscape=on'. > > > > If we look at the other most recently added bugs like TSA and ITS, neither > > have an explicit 'auto' cmdline option. But they do have 'on' cmdline > > options. > > > > The difference between 'auto' and 'on' is that 'auto' defers to the attack > > vector controls while 'on' means 'enable this mitigation if the CPU is > > vulnerable' (as opposed to 'force' which will enable it even if not > > vulnerable). > > > > An explicit 'vmscape=on' could give users an option to ensure the > > mitigation is used (regardless of attack vectors) and could choose the best > > mitigation (BHB clear if available, otherwise IBPB). > > I thought the whole idea of attack vectors was because the gazillion options > for gazillion mitigation became untenable over time. Now, what you are > saying is - on top of the simplification, let's add yet more options to > override the attack vectors o_O. IMO, having 'force' is sufficient to cover > scenarios where people really want this mitigation - either because they > know better, or because they want to test something. Agree with that in general. It all boils down to: Is there are use case where people would want to use attack vector controls but want to override one specific mitigation? > Force also covers the "on" case, so let's leave it at "on" for attack vector > support, and 'force' for everything else Force covers the "on" case with a caveat that it also forces the BUG on unaffected CPUs. Given that attack vectors do allow all other mitigations to override the attack vector settings, VMSCAPE should be no different. Or else we introduce a change to let attack vectors reign all mitigations.
On Mon, Oct 27, 2025, Pawan Gupta wrote: > IBPB mitigation for VMSCAPE is an overkill for CPUs that are only affected > by the BHI variant of VMSCAPE. On such CPUs, eIBRS already provides > indirect branch isolation between guest and host userspace. But, a guest > could still poison the branch history. > > To mitigate that, use the recently added clear_bhb_long_loop() to isolate > the branch history between guest and userspace. Add cmdline option > 'vmscape=on' that automatically selects the appropriate mitigation based > on the CPU. > > Acked-by: David Kaplan <david.kaplan@amd.com> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> > --- > Documentation/admin-guide/hw-vuln/vmscape.rst | 8 ++++ > Documentation/admin-guide/kernel-parameters.txt | 4 +- > arch/x86/include/asm/cpufeatures.h | 1 + > arch/x86/include/asm/entry-common.h | 12 +++--- > arch/x86/include/asm/nospec-branch.h | 2 +- > arch/x86/kernel/cpu/bugs.c | 53 ++++++++++++++++++------- > arch/x86/kvm/x86.c | 5 ++- > 7 files changed, 61 insertions(+), 24 deletions(-) For the KVM changes, Acked-by: Sean Christopherson <seanjc@google.com>
On Wed, Oct 29, 2025 at 03:47:54PM -0700, Sean Christopherson wrote: > On Mon, Oct 27, 2025, Pawan Gupta wrote: > > IBPB mitigation for VMSCAPE is an overkill for CPUs that are only affected > > by the BHI variant of VMSCAPE. On such CPUs, eIBRS already provides > > indirect branch isolation between guest and host userspace. But, a guest > > could still poison the branch history. > > > > To mitigate that, use the recently added clear_bhb_long_loop() to isolate > > the branch history between guest and userspace. Add cmdline option > > 'vmscape=on' that automatically selects the appropriate mitigation based > > on the CPU. > > > > Acked-by: David Kaplan <david.kaplan@amd.com> > > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> > > --- > > Documentation/admin-guide/hw-vuln/vmscape.rst | 8 ++++ > > Documentation/admin-guide/kernel-parameters.txt | 4 +- > > arch/x86/include/asm/cpufeatures.h | 1 + > > arch/x86/include/asm/entry-common.h | 12 +++--- > > arch/x86/include/asm/nospec-branch.h | 2 +- > > arch/x86/kernel/cpu/bugs.c | 53 ++++++++++++++++++------- > > arch/x86/kvm/x86.c | 5 ++- > > 7 files changed, 61 insertions(+), 24 deletions(-) > > For the KVM changes, > > Acked-by: Sean Christopherson <seanjc@google.com> Thank you.
© 2016 - 2026 Red Hat, Inc.