Re: [PATCH v8 08/10] x86/vmscape: Deploy BHB clearing mitigation

[bot+bpf-ci]

> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index a7dee7ec6ea39..8cacd9474fdf0 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c

[ ... ]

> @@ -3136,6 +3149,8 @@ static void __init vmscape_apply_mitigation(void)
>  {
>  	if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER)
>  		static_call_update(vmscape_predictor_flush, write_ibpb);
> +	else if (vmscape_mitigation == VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER)
> +		static_call_update(vmscape_predictor_flush, clear_bhb_loop_nofence);
>  }

When vmscape_predictor_flush is set to clear_bhb_loop_nofence, the
call site in arch_exit_to_user_mode_prepare() becomes:

    static_call_cond(vmscape_predictor_flush)();
    this_cpu_write(x86_predictor_flush_exit_to_user, false);

The comment above clear_bhb_loop_nofence() in entry_64.S says:

    Note, callers should use a speculation barrier like LFENCE
    immediately after a call to this function to ensure BHB is
    cleared before indirect branches.

Every other callsite follows this requirement, e.g. in
CLEAR_BRANCH_HISTORY and CLEAR_BRANCH_HISTORY_VMEXIT:

    call clear_bhb_loop_nofence; lfence

The previous static_call target, write_ibpb(), uses wrmsr which is
serializing and inherently acts as a speculation barrier. But
clear_bhb_loop_nofence() is just a loop that fills the BHB -- it is
not serializing.

Without an lfence after the static_call, is there a speculative
window where indirect branches could execute using stale
(guest-controlled) branch history before the BHB clear takes
architectural effect?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23506000396