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] [day] [month] [year] [list]

Message-ID: <20251104233639.luharyaq5twafmlk@desk>
Date: Tue, 4 Nov 2025 15:36:39 -0800
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.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 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.