On Tue, Aug 11, 2026 at 7:23 AM Will Deacon <[email protected]> wrote: > > On Tue, Aug 11, 2026 at 03:18:17PM +0200, Ard Biesheuvel wrote: > > > > On Tue, 11 Aug 2026, at 14:02, Ard Biesheuvel wrote: > > > On Tue, 11 Aug 2026, at 11:44, Will Deacon wrote: > > >> On Mon, Aug 10, 2026 at 09:41:35AM -0700, Nick Desaulniers wrote: > > > > > >>> Sure, but let's replace this with a link to a bug report in llvm's > > >>> issue tracker? > > >> > > >> Yes, please! I can apply the patch once we have the bug number. > > >> > > > > > > I can look into that. > > > > https://github.com/llvm/llvm-project/issues/215547 > > Thanks, Ard. I've ended up with the patch below.
What's the extent that HAVE_LIVEPATCH will be used? Does this penalize kernels built with BTI in favor of HAVE_LIVEPATCH? For example, with my Android hat on, if we have a kernel that's built with ARM64_BTI_KERNEL=y, and _dont_ use HAVE_LIVEPATCH, we're going to turn off BTI for a feature we're not using? But maybe we _do_ intend to use HAVE_LIVEPATCH, and my assumption was wrong? > > Will > > --->8 > > 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. > > Clang 21+ omits the landing pad for static functions which can only be > reached by a direct branch. That's normally fine for ordinary modules > which only branch to global exported functions, but Mark Brown points > out [1] that this isn't guaranteed if the module branches between > sections. Futhermore, livepatch modules use klp relocations to reference > arbitrary kernel symbols, so with CONFIG_RANDOMIZE_MODULE_REGION_FULL > the module is far enough from the kernel that every R_AARCH64_CALL26 > needs a PLT. > > Put Clang 21+ in the naughty corner alongside GCC, which suffers from > the same issue, by disabling CONFIG_ARM64_BTI_KERNEL until we have a > version of the toolchain with the problem resolved. > > Cc: Ard Biesheuvel <[email protected]> > Link: > https://lore.kernel.org/r/[email protected] > [1] > Fixes: fd1e0fd71f65 ("arm64: Implement HAVE_LIVEPATCH") > Signed-off-by: Josh Poimboeuf <[email protected]> > [will: Stitched together commit message, diff and bug number] > Signed-off-by: Will Deacon <[email protected]> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index b3afe0688919..fc57d90d92c1 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -2116,6 +2116,8 @@ config ARM64_BTI_KERNEL > depends on !CC_IS_GCC || GCC_VERSION >= 100100 > # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 > depends on !CC_IS_GCC > + # https://github.com/llvm/llvm-project/issues/215547 > + depends on !CC_IS_CLANG || CLANG_VERSION < 210000 > depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_ARGS) > help > Build the kernel with Branch Target Identification annotations > -- Thanks, ~Nick Desaulniers
