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
next prev parent 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