Re: [PATCH v3 3/3] x86/vmscape: Remove LFENCE from BHB clearing long loop

[Pawan Gupta <pawan.kumar.gupta@linux.intel.com>]

On Tue, Nov 04, 2025 at 02:35:11PM -0800, Dave Hansen wrote:
> On 11/4/25 14:01, Pawan Gupta wrote:
> > On Mon, Nov 03, 2025 at 12:45:35PM -0800, Dave Hansen wrote:
> ...
> >> Too. Much. Assembly.
> >>
> >> Is there a reason we can't do more of this in C?
> > 
> > Apart from VMSCAPE, BHB clearing is also required when entering kernel from
> > system calls. And one of the safety requirement is to absolutely not
> > execute any indirect call/jmp unless we have cleared the BHB. In a C
> > implementation we cannot guarantee that the compiler won't generate
> > indirect branches before the BHB clearing can be done.
> 
> That's a good reason, and I did forget about the CLEAR_BRANCH_HISTORY
> route to get in to this code.
> 
> But my main aversion was to having so many different functions with
> different names to do different things that are also exported to the world.
> 
> For instance, if we need an LFENCE in the entry code, we could do this:
> 
> .macro CLEAR_BRANCH_HISTORY
>         ALTERNATIVE "", "call clear_bhb_loop; lfence",\
> 			X86_FEATURE_CLEAR_BHB_LOOP
> .endm
> 
> Instead of having a LFENCE variant of clear_bhb_loop().

This makes perfect sense. I will do that.

> >> Can we have _one_ assembly function, please? One that takes the loop
> >> counts? No macros, no duplication functions. Just one:
> > 
> > This seems possible for all the C callers. ASM callers should stick to asm
> > versions of BHB clearing to guarantee the compiler did not do anything
> > funky that would break the mitigation.
> 
> ASM callers can pass arguments to functions too. ;)

Oh my comment was more from the safety perspective of compiler induced
code.

> Sure, the syscall entry path might not be the *best* place in the world
> to do that because it'll add even more noops.

Right.

> It does make me wonder if we want to deal with this more holistically
> somehow:
> 
>         /* clobbers %rax, make sure it is after saving the syscall nr */
>         IBRS_ENTER
>         UNTRAIN_RET
>         CLEAR_BRANCH_HISTORY
> 
> especially if we're creating lots and lots of variants of functions to
> keep the ALTERNATIVE noop padding short.

Hmm, mitigations that are mutually exclusive can certainly be grouped
together in an ALTERNATIVE_N block. It also has a potential to quickly
become messy. But certainly worth exploring.