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

On Tue, Aug 11, 2026 at 9:55 AM Ard Biesheuvel [off-list ref] wrote:

On Tue, 11 Aug 2026, at 18:52, Nick Desaulniers wrote:

quoted

On Tue, Aug 11, 2026 at 9:41 AM Josh Poimboeuf [off-list ref] wrote:

quoted

On Tue, Aug 11, 2026 at 09:27:28AM -0700, Nick Desaulniers wrote:

quoted

On Tue, Aug 11, 2026 at 7:23 AM Will Deacon [off-list ref] wrote:

quoted

On Tue, Aug 11, 2026 at 03:18:17PM +0200, Ard Biesheuvel wrote:

quoted

On Tue, 11 Aug 2026, at 14:02, Ard Biesheuvel wrote:

quoted

On Tue, 11 Aug 2026, at 11:44, Will Deacon wrote:

quoted

On Mon, Aug 10, 2026 at 09:41:35AM -0700, Nick Desaulniers wrote:

quoted

quoted

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?

The problem isn't specific to livepatch, livepatch just makes it easier
to hit.

Rereading Ard's report, let me see if I can articulate _how_ and tell
me if I'm still not getting it.

Let's say we have code in .init.text that calls code in .text. If
.text was placed large enough away from .init.text, we get a veneer
inserted by _the kernel_ (not the linker).  This veneer has an
indirect call to the destination. No landing pad. Boom.

Is that precise?

Yes.

Naive question: Could the machinery that emits the veneer instead emit
N veneers, one for each cross section reference?  Rather than one
veneer that could branch indirectly to N destinations (that probably
don't have landing pads), could we instead have N veneers that branch
directly to 1 location each?  Are the veneers larger than just a
branch?  Is the destination unknown when the veneers are created? This
would retain the landing pad elision optimization for .text (which is
likely run more frequently than .init.text), and you could probably
put those veneers in .init.text and throw them away with the rest of
__init.

-- 
Thanks,
~Nick Desaulniers