Re: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21

Josh Poimboeuf <[email protected]>
Newsgroups org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-toolchains,org.kernel.vger.live-patching
Message-ID <aoIEVL0M2QPNIOO3@jpoimboe>
On Sun, Aug 16, 2026 at 04:49:59PM +0300, Ard Biesheuvel wrote:
> On Sun, 16 Aug 2026, at 12:41, Will Deacon wrote:
> > Overall, it seems to me like there are three cases we need to consider
> > for re-enabling BTI in the kernel:
> >
> > 1. A cross-section call that spans beyond the 128M range and therefore
> >    needs a veneer. I think the static linker should resolve this, probably
> >    by emitting a second veneer with the landing pad. Do we know if LLD
> >    gets this right?
> >
> 
> There are two variants here:
> 
> A cross-section call .init.text to .text that spans beyond the 128M range:
> 
> 1a. inside vmlinux, which should be dealt with by the linker, but which might
> be unreliable in practice due to the lack of BTI annotations in asm files,
> missing exec permissions on ELF sections etc. This is addressed by this series,
> but is only an issue for unusually large kernel images (e.g., allyesconfig).

Right, and if we don't care about the >128MB kernel case (I have no idea
if anybody actually uses that big of a kernel?), then we can basically
just drop patches 3-11 in favor of a simple linker assertion (similar to
patches 5 and 6) which just *always* triggers a build error on a large
kernel + BTI + !COMPILE_TEST.

-- 
Josh
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.