All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,  will@kernel.org,
	catalin.marinas@arm.com, mark.rutland@arm.com,
	 Mark Brown <broonie@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH 1/2] arm64: module: Emit BTI veneers for cross-section calls
Date: Wed, 12 Aug 2026 14:52:01 -0700	[thread overview]
Message-ID: <anzo2Q-TxbB0PUhi@jpoimboe> (raw)
In-Reply-To: <20260812162058.612202-5-ardb@kernel.org>

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 <ardb@kernel.org>
> ---
>  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".

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.

-- 
Josh


  reply	other threads:[~2026-08-12 21:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 16:20 [PATCH 0/2] arm64: Implement support for BTI veneers Ard Biesheuvel
2026-08-12 16:21 ` [PATCH 1/2] arm64: module: Emit BTI veneers for cross-section calls Ard Biesheuvel
2026-08-12 21:52   ` Josh Poimboeuf [this message]
2026-08-12 16:21 ` [PATCH 2/2] DONOTMERGE: arm64: module: Test module for BTI veneers Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anzo2Q-TxbB0PUhi@jpoimboe \
    --to=jpoimboe@kernel.org \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ndesaulniers@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.