Live Patching
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	live-patching@vger.kernel.org, Song Liu <song@kernel.org>,
	Miroslav Benes <mbenes@suse.cz>, Petr Mladek <pmladek@suse.com>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Mark Brown <broonie@kernel.org>, Kees Cook <kees@kernel.org>
Subject: Re: [PATCH] arm64/module: Fix livepatch BTI exceptions with Clang 21+
Date: Tue, 11 Aug 2026 10:44:44 +0100	[thread overview]
Message-ID: <anrvDIWMNGIa4WPK@willie-the-truck> (raw)
In-Reply-To: <CAKwvOdmSVjY0TmOTc6WMmDHcLbn=tOV3R3zH_TO4zXZiYEsaBw@mail.gmail.com>

On Mon, Aug 10, 2026 at 09:41:35AM -0700, Nick Desaulniers wrote:
> On Mon, Aug 10, 2026 at 9:39 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > On Mon, Aug 10, 2026 at 06:12:10PM +0200, Ard Biesheuvel wrote:
> > > On Mon, 10 Aug 2026, at 17:48, Josh Poimboeuf wrote:
> > > > In which case I think to properly support BTI going forward we would
> > > > need two "veneers"?  Either that or remove BTI kernel support
> > > > altogether.
> > > >
> > >
> > > Yeah, it seems we did not argue our case convincingly: their assumption
> > > that veneers/PLTs can be placed within -/+ 128M of their target does not
> > > hold for us. But I don't think it holds for .text sections larger than
> > > 128M either, so I'm not convinced their reasoning is sound even for the
> > > general case.
> > >
> > > I suppose we could special-case the PLT logic to use direct branches
> > > where possible, which would probably catch most of these (assuming
> > > .text and .init.text tend to end up close to each other also for KLP
> > > modules)
> > >
> > > For the remaining cases, we'd indeed need a second veneer at the callee
> > > end (i.e., inside .text in this case) that is emitted when resolving a
> > > cross-section indirect call to a function that lacks the BTI landing
> > > pad. But that would be its sole purpose, so I don't think we should go
> > > down this route. Instead, the 'address taken' check should include 'called
> > > directly from a different section'. Emitting veneers to work around a
> > > compiler optimization is just plain silly.
> > >
> > > I'll try and poke people on the Clang side of things to revisit this.
> > > I guess that leaves kernel BTI broken for the foreseeable future but so
> > > be it.
> >
> > Ok, so for now I suppose we need something like so?
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 06b30924509ac..972988238f367 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -2117,6 +2117,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/commit/7af2b51e761f49974a64c3009882239cea618f2a
> 
> Sure, but let's replace this with a link to a bug report in llvm's
> issue tracker? I meet with Arm's toolchain team (of which Simon
> is...on or adjacent to). I can bring this up then.

Yes, please! I can apply the patch once we have the bug number.

Will

  reply	other threads:[~2026-08-11  9:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 21:46 [PATCH] arm64/module: Fix livepatch BTI exceptions with Clang 21+ Josh Poimboeuf
2026-08-07 22:00 ` sashiko-bot
2026-08-10 10:31 ` Will Deacon
2026-08-10 15:48   ` Josh Poimboeuf
2026-08-10 16:12     ` Ard Biesheuvel
2026-08-10 16:39       ` Josh Poimboeuf
2026-08-10 16:41         ` Nick Desaulniers
2026-08-11  9:44           ` Will Deacon [this message]
2026-08-11 12:02             ` Ard Biesheuvel
2026-08-11 13:18               ` Ard Biesheuvel
2026-08-11 14:23                 ` Will Deacon
2026-08-11 14:55                   ` Ard Biesheuvel
2026-08-11 15:05                     ` Josh Poimboeuf
2026-08-11 16:27                   ` Nick Desaulniers
2026-08-11 16:41                     ` Josh Poimboeuf
2026-08-11 16:52                       ` Nick Desaulniers
2026-08-11 16:54                         ` Ard Biesheuvel
2026-08-11 17:05                           ` Nick Desaulniers
2026-08-11 17:08                             ` Ard Biesheuvel
2026-08-11 16:17                 ` Nick Desaulniers
2026-08-11 17:23                   ` Mark Brown
2026-08-10 16:25   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anrvDIWMNGIa4WPK@willie-the-truck \
    --to=will@kernel.org \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mbenes@suse.cz \
    --cc=ndesaulniers@google.com \
    --cc=pmladek@suse.com \
    --cc=song@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox