On Tue, 11 Aug 2026, at 19:05, Nick Desaulniers wrote:
> On Tue, Aug 11, 2026 at 9:55 AM Ard Biesheuvel <[email protected]> wrote:
>>
>>
>> On Tue, 11 Aug 2026, at 18:52, Nick Desaulniers wrote:
>> > On Tue, Aug 11, 2026 at 9:41 AM Josh Poimboeuf <[email protected]> wrote:
>> >>
>> >> On Tue, Aug 11, 2026 at 09:27:28AM -0700, Nick Desaulniers wrote:
>> >> > 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?
>> >>
>> >> 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.
>
The current veneer code emits veneers close to the call site, so that the
veneer is in range for the caller.
These BTI veneers need to be emitted at the target end, so that the real
target is withing direct branching range of the veneer.
The PLT veneers are 12 bytes (ADRP + ADD + BR). These BTI veneers will
need to be BTI_C + B, so 8 bytes.
I'm prototyping something atm that may be able to address the .init.text
vs .text issue. Fixing livepatch is a taller order.
