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.
