On Mon, Aug 10, 2026 at 09:41:35AM -0700, Nick Desaulniers wrote: > 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.
Yes, please! I can apply the patch once we have the bug number. Will
