On Mon, Aug 10, 2026 at 9:39 AM Josh Poimboeuf <[email protected]> wrote: > > 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
Sure, but let's replace this with a link to a bug report in llvm's issue tracker? I meet with Arm's toolchain team (of which Simon is...on or adjacent to). I can bring this up then. > + 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 -- Thanks, ~Nick Desaulniers
