On Mon, Aug 10, 2026 at 06:12:10PM +0200, Ard Biesheuvel wrote:
> On Mon, 10 Aug 2026, at 17:48, Josh Poimboeuf wrote:
> > In which case I think to properly support BTI going forward we would
> > need two "veneers"? Either that or remove BTI kernel support
> > altogether.
> >
>
> Yeah, it seems we did not argue our case convincingly: their assumption
> that veneers/PLTs can be placed within -/+ 128M of their target does not
> hold for us. But I don't think it holds for .text sections larger than
> 128M either, so I'm not convinced their reasoning is sound even for the
> general case.
>
> I suppose we could special-case the PLT logic to use direct branches
> where possible, which would probably catch most of these (assuming
> .text and .init.text tend to end up close to each other also for KLP
> modules)
>
> For the remaining cases, we'd indeed need a second veneer at the callee
> end (i.e., inside .text in this case) that is emitted when resolving a
> cross-section indirect call to a function that lacks the BTI landing
> pad. But that would be its sole purpose, so I don't think we should go
> down this route. Instead, the 'address taken' check should include 'called
> directly from a different section'. Emitting veneers to work around a
> compiler optimization is just plain silly.
>
> I'll try and poke people on the Clang side of things to revisit this.
> I guess that leaves kernel BTI broken for the foreseeable future but so
> be it.
Ok, so for now I suppose we need something like so?
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 06b30924509ac..972988238f367 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2117,6 +2117,8 @@ config ARM64_BTI_KERNEL
depends on !CC_IS_GCC || GCC_VERSION >= 100100
# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
depends on !CC_IS_GCC
+ #
https://github.com/llvm/llvm-project/commit/7af2b51e761f49974a64c3009882239cea618f2a
+ depends on !CC_IS_CLANG || CLANG_VERSION < 210000
depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_ARGS)
help
Build the kernel with Branch Target Identification annotations
