Re: [PATCH] arm64/module: Fix livepatch BTI exceptions with Clang 21+

On Tue, Aug 11, 2026 at 04:55:37PM +0200, Ard Biesheuvel wrote:
> 
> On Tue, 11 Aug 2026, at 16:23, Will Deacon wrote:
> 
> > Author: Josh Poimboeuf <[email protected]>
> > Date:   Tue Aug 11 14:11:44 2026 +0000
> >
> >     arm64: bti: Disable in-kernel BTI with recent versions of Clang
> >    
> >     The following BTI exception was seen when loading a livepatch module:
> >    
> >       Internal error: Oops - BTI: 0000000036000001 [#1]  SMP
> >       pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=jc)
> >       pc : kill_orphaned_pgrp+0x0/0x150
> >       lr : do_exit+0x498/0xaf0 [livepatch_combined]
> >    
> >     The problem is that the patch module's do_exit() is branching to a
> >     static function in vmlinux using a module PLT veneer (indirect branch),
> >     but the target function doesn't have a BTI landing pad.
> >    
> 
> I had missed this bit before, i.e., the fact that the target is a static
> function inside vmlinux.
> 
> The lack of a BTI landing pad suggests that the address of this function
> is never taken either, and so the symbol in question is not exported to
> modules, right?
> 
> Does KLP make any special accommodations to ensure that this is safe? Otherwise,
> BTI is not the only potential issue: the compiler may apply interprocedural
> optimizations, and the function in question may not be AAPCS64 compliant as
> a result.
> 
> It also means treating cross-section jumps as indirect calls in the BTI
> landing pad elision heuristic would not work around the issue here.

Yes, the livepatch module creation process takes interprocedural
optimizations into account.

With kpatch-build and the new in-tree klp-build (x86 only, arm64 coming
soon), it does a binary diff between the old and new kernels, and
extracts the changed functions.  So if the interface between caller and
callee changes, they both get patched.

-- 
Josh