On Mon, Aug 10, 2026 at 06:12:10PM +0200, Ard Biesheuvel wrote:
On Mon, 10 Aug 2026, at 17:48, Josh Poimboeuf wrote:
quoted
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