Re: Revisiting c0a454b9044f

[Nathan Chancellor <nathan@kernel.org>]

On Tue, Jul 15, 2025 at 12:16:07PM +0100, Mark Rutland wrote:
> On Mon, Jul 14, 2025 at 12:52:05PM -0700, Nathan Chancellor wrote:
> > I am looking to potentially bump the minimum version of LLVM for
> > building the kernel to 15.0.0 after the next merge window. In my quest
> > to look for workarounds that can be dropped, I noticed that
> > CONFIG_ARM64_BTI_KERNEL was disabled unconditionally for GCC in commit
> > c0a454b9044f ("arm64/bti: Disable in kernel BTI when cross section
> > thunks are broken") as a result of [1]. Looking at that GCC report, it
> > seems like the AArch64 ABI now documents [2] the GNU toolchain's
> > behavior as expected 
> 
> For context, at the time of commit c0a454b9044f, GNU LD did not handle
> this appropriately, leading to runtime BTI failures where two sections
> were too far apart.
> 
> GNU LD was subsequently fixed, and the ABI documentation was updated,
> but I'm not sure which specific versions of GNU LD have the fix, and we
> hadn't chased that up to re-enable BTI with GCC.

Based on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671#c7 and
https://sourceware.org/bugzilla/show_bug.cgi?id=30076, it sounds like
binutils 2.41 would be the first fixed version.

> > and LLVM has been adjusted [3][4][5] to match. Do I need to block
> > CONFIG_ARM64_BTI_KERNEL from being selected with LLVM 21.0.0?
> 
> I'm missing something; why would we need to dsiable BTI in that case?

Nope, you are not missing anything, I missed the correlation between the
compiler and linker.

> The concern from the kernel side is simply whether we get unexpected BTI
> failures. IIUC so long as compiler and linker agree we should be good,
> and we simply need to forbid broken combinations.

Mark Brown did mention something about the module loader as well so I
was not sure if that was relevant here.

> > Or should the kernel adjust its expectations now that the ABI and
> > toolchains all agree?
> 
> Yes, we can probably rework this.
> 
> IIUC we'd need to forbid BTI with:
> 
> * GCC + old GNU LD
> * GCC + old LLD
> * new clang + old GNU LD
> * new clang + old LLD
> 
> ... and can enable BTI otherwise.
> 
> Does that make sense to you?

So something like this if I understand correctly?

Cheers,
Nathan

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 393d71124f5d..fe523f9f2d61 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2097,7 +2097,11 @@ config ARM64_BTI_KERNEL
 	# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
 	depends on !CC_IS_GCC || GCC_VERSION >= 100100
 	# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
-	depends on !CC_IS_GCC
+	# https://sourceware.org/bugzilla/show_bug.cgi?id=30076
+	depends on !CC_IS_GCC || LD_VERSION >= 24100 || LLD_VERSION >= 210000
+	# https://github.com/llvm/llvm-project/commit/7af2b51e761f49974a64c3009882239cea618f2a
+	# https://github.com/llvm/llvm-project/commit/098b0d18add97dea94e16006486b2fded65e228d
+	depends on !CC_IS_CLANG || CLANG_VERSION < 210000 || (CLANG_VERSION >= 210000 && (LD_VERSION >= 24100 || LLD_VERSION >= 210000))
 	depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_ARGS)
 	help
 	  Build the kernel with Branch Target Identification annotations