Revisiting c0a454b9044f

[Mark Rutland]

On Wed, Jul 16, 2025 at 12:26:41PM -0600, Nathan Chancellor wrote:
> On Tue, Jul 15, 2025 at 12:16:07PM +0100, Mark Rutland wrote:
> > 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.

Sorry, I had forgotten anout that, and that is a concern.

If a single module has executable sections placed more than 128MiB apart
we'd potentially have the same problem with any cross-section branch.
Truly handling that would be quite tricky and require a fair amount of
rework, so the best bet is probably to reject loading modules that are
too large (or where we specifically find such cross-section branches
needing veneers).

Note that exported symbols and address-taken functions should have a
BTI, so this only really matters for cross-section calls within a single
module.

I suspect it should be relatively simple but I'm not sure exactly where
to plumb that in. I can put that on my TODO list if no-one gets around
to it.

> > > 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))

Yep, something like that.

I was thinking that we could factor this out into a separate config,
like we have for BUILTIN_RETURN_ADDRESS_STRIPS_PAC, as that'll make it
easier to avoid duplication, e.g.

| config TOOLCHAIN_HAS_WORKING_BTI
| 	bool
| 	# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
| 	default n if CC_IS_GCC && GCC_VERSION < 100100
|	# Newer LD/LLD handle BTI in veneers automatically
| 	default y if LD_IS_LLD && LLD_VERSION >= 210000
| 	default y if LD_IS_GNU && LD_VERSION >= 24100
| 	# Newer clang requires newer LD/LLD above
| 	default y if CC_IS_CLANG && CLANG_VERSION < 210000
| 	default n

... and we can easily extend that to handle fixed stable versions, like with
BUILTIN_RETURN_ADDRESS_STRIPS_PAC.

Mark.