Revisiting c0a454b9044f
Mark Rutland
mark.rutland at arm.com
Thu Jul 17 06:47:23 PDT 2025
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.
More information about the linux-arm-kernel
mailing list