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
