From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B62CC490BF5 for ; Thu, 13 Aug 2026 15:53:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786636398; cv=none; b=Qua8J5TT0NDp7EkCc8MF9XOusMg0gA37VrnCArbGyTJbe2NaIvP++hkeaOIwB1Frc1NLWN2vHqcIn5noXvpenHEG9Bkg7je0DOLCH/qIJOEwKQVikyyfkq6T1go8poRncYMUXI1Y87BPC1oZImYwZojc+gPQ5vvjqLJJ/5t/DSo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786636398; c=relaxed/simple; bh=Yq6K5fhxrb2xao2t5evfWSQ2uAZ59InhJI3Z+ABnous=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VHybFZEemLxSWUytMLJKdPXTZC/UsPbs6PLWZYWaZC2jdpZBKBGbqCUaDvwfD94/LhMimr7TFmOz8Rp/U0ir10iESpIEoYH0vVRq87TAs2ya205oGyLThPKWIYuceQYbeQBh3jHlQVvHzOowr3ipnRRMoVE85/Z4r+mpayN+jY4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aQanQO+D; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aQanQO+D" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CB821F000E9; Thu, 13 Aug 2026 15:53:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786636390; bh=pojo/5ihe+x3tRo9VM4Cq8odA8bQ3ul0KyDtov7i6YE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=aQanQO+DNNS5jcSgP9fd7qtYMs2Pe1fwqXr8IVo5Xg/278WctdtrgvZH2RFhMI2Bq Vys2IlJu8+7RNtHd9GFVY+iZtms6peyf+l/QcBbZgx/Gm3BTqPPiHZEo/kXxrgWzjc WPKT8cX+3DYFceElFmHFZIFbijDudJoKEGdVCgg1z/3Ww3hasXEtRaTKqzUh6T49L1 l5Fp3Rmmm5lqxD6u+u+N1Z/74u6iRNy/pJlQxMxwykGwK1H8NEM2EOdkTtEiNyGyBX 1vA0PYo89Qz1l11NYxjnK0oo7Jnwel+/2VO2EbK3Q1rMaEkOPDQRJhJZ535zBUTP1q fYS8OJRhxBvHg== Date: Thu, 13 Aug 2026 08:53:07 -0700 From: Josh Poimboeuf To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Will Deacon , Catalin Marinas , Mark Rutland , Mark Brown , Nick Desaulniers Subject: Re: [PATCH 1/2] arm64: module: Emit BTI veneers for cross-section calls Message-ID: References: <20260812162058.612202-4-ardb@kernel.org> <20260812162058.612202-5-ardb@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Aug 13, 2026 at 09:34:44AM +0300, Ard Biesheuvel wrote: > > On Thu, 13 Aug 2026, at 00:52, Josh Poimboeuf wrote: > > On Wed, Aug 12, 2026 at 06:21:00PM +0200, Ard Biesheuvel wrote: > >> The compiler is permitted to omit BTI landing pads from static functions > >> that never have their address taken, but are only called directly, even > >> if those calls originate from other code sections. > >> > >> This means that calls into a module's .text section from .init.text, > >> which may need to be routed via a PLT if .text is out of direct > >> branching range, may result in BTI exceptions due to the indirect calls > >> performed by the PLT veneers. (Note that calls to .init.text from .text > >> are not allowed.) > >> > >> The 'solution' is to emit yet another veneer - this is what the ELF > >> psABI for AArch64 mandates in this case. > >> > >> So derive an upper bound for the number of veneers that may be needed in > >> the core module region to ensure that any call from init code that ends > >> up needing a PLT can be directed at a veneer with a BTI landing pad, and > >> allocate the additional space. > >> > >> Then, emit these veneers as needed, i.e., only when emitting a PLT entry > >> for a call from an init code section to a normal code section in the > >> same module. In practice, this only occurs when a module's .init.text > >> happens to be allocated far away from its .text section, which might > >> happen when the initial 128M 'near' module region runs out of space > >> between allocating the core module and allocating its init region. > >> > >> Signed-off-by: Ard Biesheuvel > >> --- > >> arch/arm64/Kconfig | 2 - > >> arch/arm64/include/asm/module.h | 12 ++ > >> arch/arm64/include/asm/module.lds.h | 3 + > >> arch/arm64/kernel/module-plts.c | 128 +++++++++++++++++++- > >> 4 files changed, 138 insertions(+), 7 deletions(-) > >> > >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > >> index b3afe0688919..25fa80b5591d 100644 > >> --- a/arch/arm64/Kconfig > >> +++ b/arch/arm64/Kconfig > >> @@ -2114,8 +2114,6 @@ config ARM64_BTI_KERNEL > >> depends on CC_HAS_BRANCH_PROT_PAC_RET_BTI > >> # 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 > > > > This doesn't work for livepatch though, and removing the "depends on > > !CC_IS_GCC" is a livepatch regression as it broadly increases the > > likelihood of ARM64_BTI_KERNEL (default y) getting enabled. > > > > So "livepatch broken on arm64 clang 21+" now becomes "livepatch broken > > on arm64". > > > > ... when kernel mode BTI is enabled. > > I have no insight into which pieces of livepatch for arm64 are actually > upstream. Is it just the tooling that is missing? In this case, though, > I think HAVE_LIVEPATCH should depend on !ARM64_BTI_KERNEL, rather than > the other way around. I can add that in v2. So arm64 has supported livepatch since HAVE_LIVEPATCH was introduced with fd1e0fd71f65 ("arm64: Implement HAVE_LIVEPATCH"). The only production tooling for arm64 livepatch is out-of-tree, though it's possible to create some rudimentary livepatches in tree (see samples/livepatch). Though I think klp-build for arm64 is solid and ready to be merged soon. > > So either ARM64_BTI_KERNEL needs to depend on !LIVEPATCH (which will > > keep BTI disabled for most distros), or we need a different approach > > which uses __vmalloc_node_range() to allocate a veneer within 128MB of > > the target. I can try to write that up. > > > > Yes. Or pre-allocate some space in vmlinux for this purpose. I suppose > we might just use -fpatchable-function-entry for this, and add one > additional NOP to vmlinux for livepatch kernels, so that a landing pad > can be patched in as needed. AFAIR the ftrace code already deals with > the BTI landing pads gracefully. It looked to me like ftrace is using RET instead of BR, which I proposed to do in the veneer, but Will objected: https://lore.kernel.org/ed4fe1f95071897859ec7fbe9176246cbd4962bf.1786138806.git.jpoimboe@kernel.org I have a patch using __vmalloc_node_range() to allocate the 2nd veneer near the target, which seems to work fine, I'll post it later. > > vmlinux text size > 128MB? > > > > The linker adds veneers for that case, but doesn't make them > > BTI-friendly unless GNU_PROPERTY_AARCH64_FEATURE_1_BTI is set on *all* > > .o files, which is not currently happening for .S files. > > > > I think we should fix that. > > > And when I force that bit with "-z force-bti" on a 700MB text > > allyesconfig vmlinux with 22k linker-created veneers, it's crashes the > > GNU linker :-/ > > > > Seems kernel BTI is borked all around... > > allyesconfig is useful, but it is not a configuration that is expected > to boot successfully. But it certainly shouldn't crash the linker, so > this is something we should report to the binutils folks. Yeah, working on reporting that now, I have a couple of small reproducers. The crash isn't specific to allyesconfig though. It doesn't like the use of PROVIDE() in linker scripts, apparently... -- Josh