On Sun, Aug 16, 2026 at 04:49:59PM +0300, Ard Biesheuvel wrote:
On Sun, 16 Aug 2026, at 12:41, Will Deacon wrote:
quoted
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