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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c6b9a696-975f-4dfa-bf65-9a1e983fab54@intel.com>
Date: Tue, 4 Nov 2025 14:35:11 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
Cc: x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
 Josh Poimboeuf <jpoimboe@...nel.org>, David Kaplan <david.kaplan@....com>,
 Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini
 <pbonzini@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, linux-kernel@...r.kernel.org,
 kvm@...r.kernel.org, Asit Mallick <asit.k.mallick@...el.com>,
 Tao Zhang <tao1.zhang@...el.com>
Subject: Re: [PATCH v3 3/3] x86/vmscape: Remove LFENCE from BHB clearing long
 loop

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().

>> 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. ;)

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

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.