* [PATCH v2 0/3] VMSCAPE optimization for BHI variant
@ 2025-10-16 1:51 Pawan Gupta
2025-10-16 1:51 ` [PATCH v2 1/3] x86/bhi: Add BHB clearing for CPUs with larger branch history Pawan Gupta
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-10-16 1:51 UTC (permalink / raw)
To: x86, H. Peter Anvin, Josh Poimboeuf, David Kaplan,
Sean Christopherson, Paolo Bonzini
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang
v2:
- Added check for IBPB feature in vmscape_select_mitigation(). (David)
- s/vmscape=auto/vmscape=on/ (David)
- Added patch to remove LFENCE from VMSCAPE BHB-clear sequence.
- Rebased to v6.18-rc1.
v1: https://lore.kernel.org/r/20250924-vmscape-bhb-v1-0-da51f0e1934d@linux.intel.com
Hi All,
These patches aim to improve the performance of a recent mitigation for
VMSCAPE[1] vulnerability. This improvement is relevant for BHI variant of
VMSCAPE that affect Alder Lake and newer processors.
The current mitigation approach uses IBPB on kvm-exit-to-userspace for all
affected range of CPUs. This is an overkill for CPUs that are only affected
by the BHI variant. On such CPUs clearing the branch history is sufficient
for VMSCAPE, and also more apt as the underlying issue is due to poisoned
branch history.
Roadmap:
- First patch introduces clear_bhb_long_loop() for processors with larger
branch history tables.
- Second patch replaces IBPB on exit-to-userspace with branch history
clearing sequence.
Below is the iPerf data for transfer between guest and host, comparing IBPB
and BHB-clear mitigation. BHB-clear shows performance improvement over IBPB
in most cases.
Platform: Emerald Rapids
Baseline: vmscape=off
(pN = N parallel connections)
| iPerf user-net | IBPB | BHB Clear |
|----------------|---------|-----------|
| UDP 1-vCPU_p1 | -12.5% | 1.3% |
| TCP 1-vCPU_p1 | -10.4% | -1.5% |
| TCP 1-vCPU_p1 | -7.5% | -3.0% |
| UDP 4-vCPU_p16 | -3.7% | -3.7% |
| TCP 4-vCPU_p4 | -2.9% | -1.4% |
| UDP 4-vCPU_p4 | -0.6% | 0.0% |
| TCP 4-vCPU_p4 | 3.5% | 0.0% |
| iPerf bridge-net | IBPB | BHB Clear |
|------------------|---------|-----------|
| UDP 1-vCPU_p1 | -9.4% | -0.4% |
| TCP 1-vCPU_p1 | -3.9% | -0.5% |
| UDP 4-vCPU_p16 | -2.2% | -3.8% |
| TCP 4-vCPU_p4 | -1.0% | -1.0% |
| TCP 4-vCPU_p4 | 0.5% | 0.5% |
| UDP 4-vCPU_p4 | 0.0% | 0.9% |
| TCP 1-vCPU_p1 | 0.0% | 0.9% |
| iPerf vhost-net | IBPB | BHB Clear |
|-----------------|---------|-----------|
| UDP 1-vCPU_p1 | -4.3% | 1.0% |
| TCP 1-vCPU_p1 | -3.8% | -0.5% |
| TCP 1-vCPU_p1 | -2.7% | -0.7% |
| UDP 4-vCPU_p16 | -0.7% | -2.2% |
| TCP 4-vCPU_p4 | -0.4% | 0.8% |
| UDP 4-vCPU_p4 | 0.4% | -0.7% |
| TCP 4-vCPU_p4 | 0.0% | 0.6% |
[1] https://comsec.ethz.ch/research/microarch/vmscape-exposing-and-exploiting-incomplete-branch-predictor-isolation-in-cloud-environments/
---
Pawan Gupta (3):
x86/bhi: Add BHB clearing for CPUs with larger branch history
x86/vmscape: Replace IBPB with branch history clear on exit to userspace
x86/vmscape: Remove LFENCE from BHB clearing long loop
Documentation/admin-guide/hw-vuln/vmscape.rst | 8 ++++
Documentation/admin-guide/kernel-parameters.txt | 4 +-
arch/x86/entry/entry_64.S | 63 ++++++++++++++++++-------
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/entry-common.h | 12 +++--
arch/x86/include/asm/nospec-branch.h | 5 +-
arch/x86/kernel/cpu/bugs.c | 53 +++++++++++++++------
arch/x86/kvm/x86.c | 5 +-
8 files changed, 110 insertions(+), 41 deletions(-)
---
base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
change-id: 20250916-vmscape-bhb-d7d469977f2f
Best regards,
--
Pawan
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 1/3] x86/bhi: Add BHB clearing for CPUs with larger branch history
2025-10-16 1:51 [PATCH v2 0/3] VMSCAPE optimization for BHI variant Pawan Gupta
@ 2025-10-16 1:51 ` Pawan Gupta
2025-10-16 1:52 ` [PATCH v2 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace Pawan Gupta
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-10-16 1:51 UTC (permalink / raw)
To: x86, H. Peter Anvin, Josh Poimboeuf, David Kaplan,
Sean Christopherson, Paolo Bonzini
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang
Add a version of clear_bhb_loop() that works on CPUs with larger branch
history table such as Alder Lake and newer. This could serve as a cheaper
alternative to IBPB mitigation for VMSCAPE.
clear_bhb_loop() and the new clear_bhb_long_loop() only differ in the loop
counter. Convert the asm implementation of clear_bhb_loop() into a macro
that is used by both the variants, passing counter as an argument.
There is no difference in the output of:
$ objdump --disassemble=clear_bhb_loop vmlinux
before and after this commit.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/entry/entry_64.S | 47 ++++++++++++++++++++++++++----------
arch/x86/include/asm/nospec-branch.h | 3 +++
2 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index ed04a968cc7d0095ab0185b2e3b5beffb7680afd..f5f62af080d8ec6fe81e4dbe78ce44d08e62aa59 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1499,11 +1499,6 @@ SYM_CODE_END(rewind_stack_and_make_dead)
* from the branch history tracker in the Branch Predictor, therefore removing
* user influence on subsequent BTB lookups.
*
- * It should be used on parts prior to Alder Lake. Newer parts should use the
- * BHI_DIS_S hardware control instead. If a pre-Alder Lake part is being
- * virtualized on newer hardware the VMM should protect against BHI attacks by
- * setting BHI_DIS_S for the guests.
- *
* CALLs/RETs are necessary to prevent Loop Stream Detector(LSD) from engaging
* and not clearing the branch history. The call tree looks like:
*
@@ -1529,11 +1524,12 @@ SYM_CODE_END(rewind_stack_and_make_dead)
* that all RETs are in the second half of a cacheline to mitigate Indirect
* Target Selection, rather than taking the slowpath via its_return_thunk.
*/
-SYM_FUNC_START(clear_bhb_loop)
+.macro __CLEAR_BHB_LOOP outer_loop_count:req, inner_loop_count:req
ANNOTATE_NOENDBR
push %rbp
mov %rsp, %rbp
- movl $5, %ecx
+
+ movl $\outer_loop_count, %ecx
ANNOTATE_INTRA_FUNCTION_CALL
call 1f
jmp 5f
@@ -1542,29 +1538,54 @@ SYM_FUNC_START(clear_bhb_loop)
* Shift instructions so that the RET is in the upper half of the
* cacheline and don't take the slowpath to its_return_thunk.
*/
- .skip 32 - (.Lret1 - 1f), 0xcc
+ .skip 32 - (.Lret1_\@ - 1f), 0xcc
ANNOTATE_INTRA_FUNCTION_CALL
1: call 2f
-.Lret1: RET
+.Lret1_\@:
+ RET
.align 64, 0xcc
/*
- * As above shift instructions for RET at .Lret2 as well.
+ * As above shift instructions for RET at .Lret2_\@ as well.
*
- * This should be ideally be: .skip 32 - (.Lret2 - 2f), 0xcc
+ * This should be ideally be: .skip 32 - (.Lret2_\@ - 2f), 0xcc
* but some Clang versions (e.g. 18) don't like this.
*/
.skip 32 - 18, 0xcc
-2: movl $5, %eax
+2: movl $\inner_loop_count, %eax
3: jmp 4f
nop
4: sub $1, %eax
jnz 3b
sub $1, %ecx
jnz 1b
-.Lret2: RET
+.Lret2_\@:
+ RET
5: lfence
+
pop %rbp
RET
+.endm
+
+/*
+ * This should be used on parts prior to Alder Lake. Newer parts should use the
+ * BHI_DIS_S hardware control instead. If a pre-Alder Lake part is being
+ * virtualized on newer hardware the VMM should protect against BHI attacks by
+ * setting BHI_DIS_S for the guests.
+ */
+SYM_FUNC_START(clear_bhb_loop)
+ __CLEAR_BHB_LOOP 5, 5
SYM_FUNC_END(clear_bhb_loop)
EXPORT_SYMBOL_GPL(clear_bhb_loop)
STACK_FRAME_NON_STANDARD(clear_bhb_loop)
+
+/*
+ * A longer version of clear_bhb_loop to ensure that the BHB is cleared on CPUs
+ * with larger branch history tables (i.e. Alder Lake and newer). BHI_DIS_S
+ * protects the kernel, but to mitigate the guest influence on the host
+ * userspace either IBPB or this sequence should be used. See VMSCAPE bug.
+ */
+SYM_FUNC_START(clear_bhb_long_loop)
+ __CLEAR_BHB_LOOP 12, 7
+SYM_FUNC_END(clear_bhb_long_loop)
+EXPORT_SYMBOL_GPL(clear_bhb_long_loop)
+STACK_FRAME_NON_STANDARD(clear_bhb_long_loop)
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 08ed5a2e46a5fd790bcb1b73feb6469518809c06..49707e563bdf71bdd05d3827f10dd2b8ac6bca2c 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -388,6 +388,9 @@ extern void write_ibpb(void);
#ifdef CONFIG_X86_64
extern void clear_bhb_loop(void);
+extern void clear_bhb_long_loop(void);
+#else
+static inline void clear_bhb_long_loop(void) {}
#endif
extern void (*x86_return_thunk)(void);
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v2 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace
2025-10-16 1:51 [PATCH v2 0/3] VMSCAPE optimization for BHI variant Pawan Gupta
2025-10-16 1:51 ` [PATCH v2 1/3] x86/bhi: Add BHB clearing for CPUs with larger branch history Pawan Gupta
@ 2025-10-16 1:52 ` Pawan Gupta
2025-10-20 16:10 ` Sean Christopherson
2025-10-27 21:30 ` Pawan Gupta
2025-10-16 1:52 ` [PATCH v2 3/3] x86/vmscape: Remove LFENCE from BHB clearing long loop Pawan Gupta
2025-10-16 15:57 ` [PATCH v2 0/3] VMSCAPE optimization for BHI variant Kaplan, David
3 siblings, 2 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-10-16 1:52 UTC (permalink / raw)
To: x86, H. Peter Anvin, Josh Poimboeuf, David Kaplan,
Sean Christopherson, Paolo Bonzini
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang
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.
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..b7b9af1b641385b8283edf2449578ff65e5bd6df 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_pred_flush_pending))) {
+ if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
+ indirect_branch_prediction_barrier();
+ else if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_EXIT_TO_USER))
+ clear_bhb_long_loop();
+
+ this_cpu_write(x86_pred_flush_pending, 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..00730cc22c2e7115f6dbb38a1ed8d10383ada5c0 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_pred_flush_pending);
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 6a526ae1fe9933229947db5b7676a18328fe2204..02fd37bf4e6d77494c72806775f4415a27652206 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_pred_flush_pending);
+EXPORT_PER_CPU_SYMBOL_GPL(x86_pred_flush_pending);
u64 x86_pred_cmd __ro_after_init = PRED_CMD_IBPB;
@@ -3202,13 +3201,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 =
@@ -3226,6 +3227,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);
}
@@ -3236,18 +3239,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)
@@ -3266,6 +3286,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
@@ -3357,6 +3379,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 42ecd093bb4c8ecfae2523b52b85779ca1e56bb5..57d26dbb43e9115880e92e448e4c018e03dca063 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_pred_flush_pending, true);
/*
* Consume any pending interrupts, including the possible source of
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v2 3/3] x86/vmscape: Remove LFENCE from BHB clearing long loop
2025-10-16 1:51 [PATCH v2 0/3] VMSCAPE optimization for BHI variant Pawan Gupta
2025-10-16 1:51 ` [PATCH v2 1/3] x86/bhi: Add BHB clearing for CPUs with larger branch history Pawan Gupta
2025-10-16 1:52 ` [PATCH v2 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace Pawan Gupta
@ 2025-10-16 1:52 ` Pawan Gupta
2025-10-16 15:57 ` [PATCH v2 0/3] VMSCAPE optimization for BHI variant Kaplan, David
3 siblings, 0 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-10-16 1:52 UTC (permalink / raw)
To: x86, H. Peter Anvin, Josh Poimboeuf, David Kaplan,
Sean Christopherson, Paolo Bonzini
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang
Long loop is used to clear the branch history when switching from a guest
to host userspace. The LFENCE barrier is not required in this case as ring
transition itself acts as a barrier.
Move the prologue, LFENCE and epilogue out of __CLEAR_BHB_LOOP macro to
allow skipping the LFENCE in the long loop variant. Rename the long loop
function to clear_bhb_long_loop_no_barrier() to reflect the change.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/entry/entry_64.S | 32 ++++++++++++++++++++------------
arch/x86/include/asm/entry-common.h | 2 +-
arch/x86/include/asm/nospec-branch.h | 4 ++--
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index f5f62af080d8ec6fe81e4dbe78ce44d08e62aa59..bb456a3c652e97f3a6fe72866b6dee04f59ccc98 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1525,10 +1525,6 @@ SYM_CODE_END(rewind_stack_and_make_dead)
* Target Selection, rather than taking the slowpath via its_return_thunk.
*/
.macro __CLEAR_BHB_LOOP outer_loop_count:req, inner_loop_count:req
- ANNOTATE_NOENDBR
- push %rbp
- mov %rsp, %rbp
-
movl $\outer_loop_count, %ecx
ANNOTATE_INTRA_FUNCTION_CALL
call 1f
@@ -1560,10 +1556,7 @@ SYM_CODE_END(rewind_stack_and_make_dead)
jnz 1b
.Lret2_\@:
RET
-5: lfence
-
- pop %rbp
- RET
+5:
.endm
/*
@@ -1573,7 +1566,15 @@ SYM_CODE_END(rewind_stack_and_make_dead)
* setting BHI_DIS_S for the guests.
*/
SYM_FUNC_START(clear_bhb_loop)
+ ANNOTATE_NOENDBR
+ push %rbp
+ mov %rsp, %rbp
+
__CLEAR_BHB_LOOP 5, 5
+
+ lfence
+ pop %rbp
+ RET
SYM_FUNC_END(clear_bhb_loop)
EXPORT_SYMBOL_GPL(clear_bhb_loop)
STACK_FRAME_NON_STANDARD(clear_bhb_loop)
@@ -1584,8 +1585,15 @@ STACK_FRAME_NON_STANDARD(clear_bhb_loop)
* protects the kernel, but to mitigate the guest influence on the host
* userspace either IBPB or this sequence should be used. See VMSCAPE bug.
*/
-SYM_FUNC_START(clear_bhb_long_loop)
+SYM_FUNC_START(clear_bhb_long_loop_no_barrier)
+ ANNOTATE_NOENDBR
+ push %rbp
+ mov %rsp, %rbp
+
__CLEAR_BHB_LOOP 12, 7
-SYM_FUNC_END(clear_bhb_long_loop)
-EXPORT_SYMBOL_GPL(clear_bhb_long_loop)
-STACK_FRAME_NON_STANDARD(clear_bhb_long_loop)
+
+ pop %rbp
+ RET
+SYM_FUNC_END(clear_bhb_long_loop_no_barrier)
+EXPORT_SYMBOL_GPL(clear_bhb_long_loop_no_barrier)
+STACK_FRAME_NON_STANDARD(clear_bhb_long_loop_no_barrier)
diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
index b7b9af1b641385b8283edf2449578ff65e5bd6df..c70454bdd0e3f544dedf582ad6f7f62e2833704c 100644
--- a/arch/x86/include/asm/entry-common.h
+++ b/arch/x86/include/asm/entry-common.h
@@ -98,7 +98,7 @@ static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs,
if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
indirect_branch_prediction_barrier();
else if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_EXIT_TO_USER))
- clear_bhb_long_loop();
+ clear_bhb_long_loop_no_barrier();
this_cpu_write(x86_pred_flush_pending, false);
}
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 00730cc22c2e7115f6dbb38a1ed8d10383ada5c0..3bcf9f180c21d468f17fa9c1210cba84a541e6ea 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -388,9 +388,9 @@ extern void write_ibpb(void);
#ifdef CONFIG_X86_64
extern void clear_bhb_loop(void);
-extern void clear_bhb_long_loop(void);
+extern void clear_bhb_long_loop_no_barrier(void);
#else
-static inline void clear_bhb_long_loop(void) {}
+static inline void clear_bhb_long_loop_no_barrier(void) {}
#endif
extern void (*x86_return_thunk)(void);
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* RE: [PATCH v2 0/3] VMSCAPE optimization for BHI variant
2025-10-16 1:51 [PATCH v2 0/3] VMSCAPE optimization for BHI variant Pawan Gupta
` (2 preceding siblings ...)
2025-10-16 1:52 ` [PATCH v2 3/3] x86/vmscape: Remove LFENCE from BHB clearing long loop Pawan Gupta
@ 2025-10-16 15:57 ` Kaplan, David
2025-10-16 17:23 ` Pawan Gupta
3 siblings, 1 reply; 10+ messages in thread
From: Kaplan, David @ 2025-10-16 15:57 UTC (permalink / raw)
To: Pawan Gupta, x86@kernel.org, H. Peter Anvin, Josh Poimboeuf,
Sean Christopherson, Paolo Bonzini
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick,
Tao Zhang
[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Sent: Wednesday, October 15, 2025 8:52 PM
> To: x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; Josh Poimboeuf
> <jpoimboe@kernel.org>; Kaplan, David <David.Kaplan@amd.com>; Sean
> Christopherson <seanjc@google.com>; Paolo Bonzini <pbonzini@redhat.com>
> Cc: linux-kernel@vger.kernel.org; kvm@vger.kernel.org; Asit Mallick
> <asit.k.mallick@intel.com>; Tao Zhang <tao1.zhang@intel.com>
> Subject: [PATCH v2 0/3] VMSCAPE optimization for BHI variant
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> v2:
> - Added check for IBPB feature in vmscape_select_mitigation(). (David)
> - s/vmscape=auto/vmscape=on/ (David)
> - Added patch to remove LFENCE from VMSCAPE BHB-clear sequence.
> - Rebased to v6.18-rc1.
>
> v1: https://lore.kernel.org/r/20250924-vmscape-bhb-v1-0-
> da51f0e1934d@linux.intel.com
>
> Hi All,
>
> These patches aim to improve the performance of a recent mitigation for
> VMSCAPE[1] vulnerability. This improvement is relevant for BHI variant of
> VMSCAPE that affect Alder Lake and newer processors.
>
> The current mitigation approach uses IBPB on kvm-exit-to-userspace for all
> affected range of CPUs. This is an overkill for CPUs that are only affected
> by the BHI variant. On such CPUs clearing the branch history is sufficient
> for VMSCAPE, and also more apt as the underlying issue is due to poisoned
> branch history.
>
> Roadmap:
>
> - First patch introduces clear_bhb_long_loop() for processors with larger
> branch history tables.
> - Second patch replaces IBPB on exit-to-userspace with branch history
> clearing sequence.
>
> Below is the iPerf data for transfer between guest and host, comparing IBPB
> and BHB-clear mitigation. BHB-clear shows performance improvement over IBPB
> in most cases.
>
> Platform: Emerald Rapids
> Baseline: vmscape=off
>
> (pN = N parallel connections)
>
> | iPerf user-net | IBPB | BHB Clear |
> |----------------|---------|-----------|
> | UDP 1-vCPU_p1 | -12.5% | 1.3% |
> | TCP 1-vCPU_p1 | -10.4% | -1.5% |
> | TCP 1-vCPU_p1 | -7.5% | -3.0% |
> | UDP 4-vCPU_p16 | -3.7% | -3.7% |
> | TCP 4-vCPU_p4 | -2.9% | -1.4% |
> | UDP 4-vCPU_p4 | -0.6% | 0.0% |
> | TCP 4-vCPU_p4 | 3.5% | 0.0% |
>
> | iPerf bridge-net | IBPB | BHB Clear |
> |------------------|---------|-----------|
> | UDP 1-vCPU_p1 | -9.4% | -0.4% |
> | TCP 1-vCPU_p1 | -3.9% | -0.5% |
> | UDP 4-vCPU_p16 | -2.2% | -3.8% |
> | TCP 4-vCPU_p4 | -1.0% | -1.0% |
> | TCP 4-vCPU_p4 | 0.5% | 0.5% |
> | UDP 4-vCPU_p4 | 0.0% | 0.9% |
> | TCP 1-vCPU_p1 | 0.0% | 0.9% |
>
> | iPerf vhost-net | IBPB | BHB Clear |
> |-----------------|---------|-----------|
> | UDP 1-vCPU_p1 | -4.3% | 1.0% |
> | TCP 1-vCPU_p1 | -3.8% | -0.5% |
> | TCP 1-vCPU_p1 | -2.7% | -0.7% |
> | UDP 4-vCPU_p16 | -0.7% | -2.2% |
> | TCP 4-vCPU_p4 | -0.4% | 0.8% |
> | UDP 4-vCPU_p4 | 0.4% | -0.7% |
> | TCP 4-vCPU_p4 | 0.0% | 0.6% |
>
> [1] https://comsec.ethz.ch/research/microarch/vmscape-exposing-and-exploiting-
> incomplete-branch-predictor-isolation-in-cloud-environments/
>
> ---
> Pawan Gupta (3):
> x86/bhi: Add BHB clearing for CPUs with larger branch history
> x86/vmscape: Replace IBPB with branch history clear on exit to userspace
> x86/vmscape: Remove LFENCE from BHB clearing long loop
>
> Documentation/admin-guide/hw-vuln/vmscape.rst | 8 ++++
> Documentation/admin-guide/kernel-parameters.txt | 4 +-
> arch/x86/entry/entry_64.S | 63 ++++++++++++++++++-------
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/include/asm/entry-common.h | 12 +++--
> arch/x86/include/asm/nospec-branch.h | 5 +-
> arch/x86/kernel/cpu/bugs.c | 53 +++++++++++++++------
> arch/x86/kvm/x86.c | 5 +-
> 8 files changed, 110 insertions(+), 41 deletions(-)
> ---
> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> change-id: 20250916-vmscape-bhb-d7d469977f2f
>
> Best regards,
> --
> Pawan
>
Looks good to me.
Acked-by: David Kaplan <david.kaplan@amd.com>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 0/3] VMSCAPE optimization for BHI variant
2025-10-16 15:57 ` [PATCH v2 0/3] VMSCAPE optimization for BHI variant Kaplan, David
@ 2025-10-16 17:23 ` Pawan Gupta
0 siblings, 0 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-10-16 17:23 UTC (permalink / raw)
To: Kaplan, David
Cc: x86@kernel.org, H. Peter Anvin, Josh Poimboeuf,
Sean Christopherson, Paolo Bonzini, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Asit Mallick, Tao Zhang
On Thu, Oct 16, 2025 at 03:57:56PM +0000, Kaplan, David wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> > -----Original Message-----
> > From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > Sent: Wednesday, October 15, 2025 8:52 PM
> > To: x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; Josh Poimboeuf
> > <jpoimboe@kernel.org>; Kaplan, David <David.Kaplan@amd.com>; Sean
> > Christopherson <seanjc@google.com>; Paolo Bonzini <pbonzini@redhat.com>
> > Cc: linux-kernel@vger.kernel.org; kvm@vger.kernel.org; Asit Mallick
> > <asit.k.mallick@intel.com>; Tao Zhang <tao1.zhang@intel.com>
> > Subject: [PATCH v2 0/3] VMSCAPE optimization for BHI variant
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > v2:
> > - Added check for IBPB feature in vmscape_select_mitigation(). (David)
> > - s/vmscape=auto/vmscape=on/ (David)
> > - Added patch to remove LFENCE from VMSCAPE BHB-clear sequence.
> > - Rebased to v6.18-rc1.
> >
> > v1: https://lore.kernel.org/r/20250924-vmscape-bhb-v1-0-
> > da51f0e1934d@linux.intel.com
> >
> > Hi All,
> >
> > These patches aim to improve the performance of a recent mitigation for
> > VMSCAPE[1] vulnerability. This improvement is relevant for BHI variant of
> > VMSCAPE that affect Alder Lake and newer processors.
> >
> > The current mitigation approach uses IBPB on kvm-exit-to-userspace for all
> > affected range of CPUs. This is an overkill for CPUs that are only affected
> > by the BHI variant. On such CPUs clearing the branch history is sufficient
> > for VMSCAPE, and also more apt as the underlying issue is due to poisoned
> > branch history.
> >
> > Roadmap:
> >
> > - First patch introduces clear_bhb_long_loop() for processors with larger
> > branch history tables.
> > - Second patch replaces IBPB on exit-to-userspace with branch history
> > clearing sequence.
> >
> > Below is the iPerf data for transfer between guest and host, comparing IBPB
> > and BHB-clear mitigation. BHB-clear shows performance improvement over IBPB
> > in most cases.
> >
> > Platform: Emerald Rapids
> > Baseline: vmscape=off
> >
> > (pN = N parallel connections)
> >
> > | iPerf user-net | IBPB | BHB Clear |
> > |----------------|---------|-----------|
> > | UDP 1-vCPU_p1 | -12.5% | 1.3% |
> > | TCP 1-vCPU_p1 | -10.4% | -1.5% |
> > | TCP 1-vCPU_p1 | -7.5% | -3.0% |
> > | UDP 4-vCPU_p16 | -3.7% | -3.7% |
> > | TCP 4-vCPU_p4 | -2.9% | -1.4% |
> > | UDP 4-vCPU_p4 | -0.6% | 0.0% |
> > | TCP 4-vCPU_p4 | 3.5% | 0.0% |
> >
> > | iPerf bridge-net | IBPB | BHB Clear |
> > |------------------|---------|-----------|
> > | UDP 1-vCPU_p1 | -9.4% | -0.4% |
> > | TCP 1-vCPU_p1 | -3.9% | -0.5% |
> > | UDP 4-vCPU_p16 | -2.2% | -3.8% |
> > | TCP 4-vCPU_p4 | -1.0% | -1.0% |
> > | TCP 4-vCPU_p4 | 0.5% | 0.5% |
> > | UDP 4-vCPU_p4 | 0.0% | 0.9% |
> > | TCP 1-vCPU_p1 | 0.0% | 0.9% |
> >
> > | iPerf vhost-net | IBPB | BHB Clear |
> > |-----------------|---------|-----------|
> > | UDP 1-vCPU_p1 | -4.3% | 1.0% |
> > | TCP 1-vCPU_p1 | -3.8% | -0.5% |
> > | TCP 1-vCPU_p1 | -2.7% | -0.7% |
> > | UDP 4-vCPU_p16 | -0.7% | -2.2% |
> > | TCP 4-vCPU_p4 | -0.4% | 0.8% |
> > | UDP 4-vCPU_p4 | 0.4% | -0.7% |
> > | TCP 4-vCPU_p4 | 0.0% | 0.6% |
> >
> > [1] https://comsec.ethz.ch/research/microarch/vmscape-exposing-and-exploiting-
> > incomplete-branch-predictor-isolation-in-cloud-environments/
> >
> > ---
> > Pawan Gupta (3):
> > x86/bhi: Add BHB clearing for CPUs with larger branch history
> > x86/vmscape: Replace IBPB with branch history clear on exit to userspace
> > x86/vmscape: Remove LFENCE from BHB clearing long loop
> >
> > Documentation/admin-guide/hw-vuln/vmscape.rst | 8 ++++
> > Documentation/admin-guide/kernel-parameters.txt | 4 +-
> > arch/x86/entry/entry_64.S | 63 ++++++++++++++++++-------
> > arch/x86/include/asm/cpufeatures.h | 1 +
> > arch/x86/include/asm/entry-common.h | 12 +++--
> > arch/x86/include/asm/nospec-branch.h | 5 +-
> > arch/x86/kernel/cpu/bugs.c | 53 +++++++++++++++------
> > arch/x86/kvm/x86.c | 5 +-
> > 8 files changed, 110 insertions(+), 41 deletions(-)
> > ---
> > base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> > change-id: 20250916-vmscape-bhb-d7d469977f2f
> >
> > Best regards,
> > --
> > Pawan
> >
>
> Looks good to me.
>
> Acked-by: David Kaplan <david.kaplan@amd.com>
Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace
2025-10-16 1:52 ` [PATCH v2 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace Pawan Gupta
@ 2025-10-20 16:10 ` Sean Christopherson
2025-10-20 20:56 ` Pawan Gupta
2025-10-27 21:30 ` Pawan Gupta
1 sibling, 1 reply; 10+ messages in thread
From: Sean Christopherson @ 2025-10-20 16:10 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, H. Peter Anvin, Josh Poimboeuf, David Kaplan, Paolo Bonzini,
linux-kernel, kvm, Asit Mallick, Tao Zhang
On Wed, Oct 15, 2025, Pawan Gupta wrote:
> diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> index 49707e563bdf71bdd05d3827f10dd2b8ac6bca2c..00730cc22c2e7115f6dbb38a1ed8d10383ada5c0 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_pred_flush_pending);
Rather than "flush pending", what about using "need" in the name to indicate that
a flush is necessary? That makes it more obvious that e.g. KVM is marking the
CPU as needing a flush by some other code, as opposed to implying that KVM itself
has a pending flush.
And maybe spell out "prediction"? Without the context of features being checked,
I don't know that I would be able to guess "prediction".
E.g. x86_need_prediction_flush?
Or x86_prediction_flush_exit_to_user if we would prefer to clarify when the flush
needs to occur?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace
2025-10-20 16:10 ` Sean Christopherson
@ 2025-10-20 20:56 ` Pawan Gupta
2025-10-20 22:24 ` Sean Christopherson
0 siblings, 1 reply; 10+ messages in thread
From: Pawan Gupta @ 2025-10-20 20:56 UTC (permalink / raw)
To: Sean Christopherson
Cc: x86, H. Peter Anvin, Josh Poimboeuf, David Kaplan, Paolo Bonzini,
linux-kernel, kvm, Asit Mallick, Tao Zhang
On Mon, Oct 20, 2025 at 09:10:17AM -0700, Sean Christopherson wrote:
> On Wed, Oct 15, 2025, Pawan Gupta wrote:
> > diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> > index 49707e563bdf71bdd05d3827f10dd2b8ac6bca2c..00730cc22c2e7115f6dbb38a1ed8d10383ada5c0 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_pred_flush_pending);
>
> Rather than "flush pending", what about using "need" in the name to indicate that
> a flush is necessary? That makes it more obvious that e.g. KVM is marking the
> CPU as needing a flush by some other code, as opposed to implying that KVM itself
> has a pending flush.
>
> And maybe spell out "prediction"? Without the context of features being checked,
> I don't know that I would be able to guess "prediction".
>
> E.g. x86_need_prediction_flush?
>
> Or x86_prediction_flush_exit_to_user if we would prefer to clarify when the flush
> needs to occur?
Ok, ya this is more clear. I would want to make a small change, instead of
"prediction_flush", "predictor_flush" reads better to me. Changing it to:
x86_predictor_flush_exit_to_user.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace
2025-10-20 20:56 ` Pawan Gupta
@ 2025-10-20 22:24 ` Sean Christopherson
0 siblings, 0 replies; 10+ messages in thread
From: Sean Christopherson @ 2025-10-20 22:24 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, H. Peter Anvin, Josh Poimboeuf, David Kaplan, Paolo Bonzini,
linux-kernel, kvm, Asit Mallick, Tao Zhang
On Mon, Oct 20, 2025, Pawan Gupta wrote:
> On Mon, Oct 20, 2025 at 09:10:17AM -0700, Sean Christopherson wrote:
> > On Wed, Oct 15, 2025, Pawan Gupta wrote:
> > > diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> > > index 49707e563bdf71bdd05d3827f10dd2b8ac6bca2c..00730cc22c2e7115f6dbb38a1ed8d10383ada5c0 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_pred_flush_pending);
> >
> > Rather than "flush pending", what about using "need" in the name to indicate that
> > a flush is necessary? That makes it more obvious that e.g. KVM is marking the
> > CPU as needing a flush by some other code, as opposed to implying that KVM itself
> > has a pending flush.
> >
> > And maybe spell out "prediction"? Without the context of features being checked,
> > I don't know that I would be able to guess "prediction".
> >
> > E.g. x86_need_prediction_flush?
> >
> > Or x86_prediction_flush_exit_to_user if we would prefer to clarify when the flush
> > needs to occur?
>
> Ok, ya this is more clear. I would want to make a small change, instead of
> "prediction_flush", "predictor_flush" reads better to me. Changing it to:
> x86_predictor_flush_exit_to_user.
LOL, see, told you I couldn't guest the word. :-D
"predictor" is way better, thanks!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace
2025-10-16 1:52 ` [PATCH v2 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace Pawan Gupta
2025-10-20 16:10 ` Sean Christopherson
@ 2025-10-27 21:30 ` Pawan Gupta
1 sibling, 0 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-10-27 21:30 UTC (permalink / raw)
To: x86, H. Peter Anvin, Josh Poimboeuf, David Kaplan,
Sean Christopherson, Paolo Bonzini
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang
On Wed, Oct 15, 2025 at 06:52:11PM -0700, 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.
[...]
> diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
> index ce3eb6d5fdf9f2dba59b7bad24afbfafc8c36918..b7b9af1b641385b8283edf2449578ff65e5bd6df 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_pred_flush_pending))) {
> + if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
> + indirect_branch_prediction_barrier();
> + else if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_EXIT_TO_USER))
I realize that IBPB and BHB clear doesn't have to be mutually exclusive.
IBPB does avoids the need to clear BHB because it flushes the indirect
branches and BHB isn't useful anymore. But, this code doesn't need to
prevent both from being executed. This should be enforced during mitigation
selection. Updating the patch to allow both here.
> + clear_bhb_long_loop();
> +
> + this_cpu_write(x86_pred_flush_pending, false);
> }
> }
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2025-10-27 21:30 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-16 1:51 [PATCH v2 0/3] VMSCAPE optimization for BHI variant Pawan Gupta
2025-10-16 1:51 ` [PATCH v2 1/3] x86/bhi: Add BHB clearing for CPUs with larger branch history Pawan Gupta
2025-10-16 1:52 ` [PATCH v2 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace Pawan Gupta
2025-10-20 16:10 ` Sean Christopherson
2025-10-20 20:56 ` Pawan Gupta
2025-10-20 22:24 ` Sean Christopherson
2025-10-27 21:30 ` Pawan Gupta
2025-10-16 1:52 ` [PATCH v2 3/3] x86/vmscape: Remove LFENCE from BHB clearing long loop Pawan Gupta
2025-10-16 15:57 ` [PATCH v2 0/3] VMSCAPE optimization for BHI variant Kaplan, David
2025-10-16 17:23 ` Pawan Gupta
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).