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?

>
> --
> Josh



-- 
Thanks,
~Nick Desaulniers

Reply via email to