Re: [PATCH v12 10/12] x86/vmscape: Deploy BHB clearing mitigation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] VMSCAPE mitigation downgrades from IBPB to BHB clear without verifying eIBRS is active, leaving host userspace vulnerable to BTB injection.
- [High] The BHB clearing sequence `clear_bhb_loop_nofence` lacks a speculation barrier (LFENCE), allowing speculative bypass of the BHI mitigation.
--

commit 23a617eeb2c65912ce9fd14bc20dacfa19110ed4
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

x86/vmscape: Deploy BHB clearing mitigation
    
IBPB mitigation for VMSCAPE is an overkill on 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. However, branch
history from guest may also influence the indirect branches in host
userspace. To mitigate the BHI aspect, use the BHB clearing sequence.

> diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
> --- a/arch/x86/include/asm/entry-common.h
> +++ b/arch/x86/include/asm/entry-common.h
[ ... ]
> @@ -84,6 +84,10 @@ static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs,
>  #endif
>  
>  	if (unlikely(this_cpu_read(x86_predictor_flush_exit_to_user))) {
> +		/*
> +		 * Since the mitigation is for userspace, an explicit
> +		 * speculation barrier is not required after flush.
> +		 */
>  		static_call_cond(vmscape_predictor_flush)();

[Severity: High]
Does omitting the speculation barrier here allow the BHB clearing loop to be
speculatively bypassed?

Since SYSRET, IRET, and SWAPGS do not serialize the processor, it appears an
attacker could poison the branch predictor to predict an early exit from the
BHB clearing loop itself.

If the CPU speculatively bypasses the loop, wouldn't it speculatively
execute host userspace indirect branches with the guest's poisoned branch
history buffer still intact?

[ ... ]
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
[ ... ]
> @@ -3114,7 +3117,17 @@ static void __init vmscape_select_mitigation(void)
>  		break;
>  
>  	case VMSCAPE_MITIGATION_AUTO:
> -		if (boot_cpu_has(X86_FEATURE_IBPB))
> +		/*
> +		 * 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 thus they do not require a
> +		 * full predictor flush.
> +		 *
> +		 * Note, in 32-bit mode BHB clear sequence is not supported.
> +		 */
> +		if (boot_cpu_has(X86_FEATURE_BHI_CTRL) && IS_ENABLED(CONFIG_X86_64))
> +			vmscape_mitigation = VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER;

[Severity: High]
Should vmscape_select_mitigation() also verify that eIBRS is currently
active before making this downgrade?

The commit message mentions that eIBRS already provides indirect branch
isolation. However, if a system boots with vmscape=auto and spectre_v2 is
set to retpoline or off, this logic changes the mitigation from
IBPB to BHB_CLEAR based solely on the BHI_CTRL hardware capability.

Without eIBRS enabled, would this leave host userspace vulnerable to
guest-to-host BTB injection (the non-BHI variant of VMSCAPE)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-vmscape-bhb-v12-0-76cbda0ae3e5@linux.intel.com?part=10