All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Will Deacon <will@kernel.org>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org,
	 linux-arm-kernel@lists.infradead.org,
	live-patching@vger.kernel.org, Song Liu <song@kernel.org>,
	 Miroslav Benes <mbenes@suse.cz>, Petr Mladek <pmladek@suse.com>,
	 Joe Lawrence <joe.lawrence@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	 Mark Brown <broonie@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	 Kees Cook <kees@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	 linux-toolchains@vger.kernel.org
Subject: Re: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21
Date: Sun, 16 Aug 2026 11:46:07 -0700	[thread overview]
Message-ID: <aoIEVL0M2QPNIOO3@jpoimboe> (raw)
In-Reply-To: <6c7153d7-67d1-46ce-afb0-688fca871c66@app.fastmail.com>

On Sun, Aug 16, 2026 at 04:49:59PM +0300, Ard Biesheuvel wrote:
> On Sun, 16 Aug 2026, at 12:41, Will Deacon wrote:
> > Overall, it seems to me like there are three cases we need to consider
> > for re-enabling BTI in the kernel:
> >
> > 1. A cross-section call that spans beyond the 128M range and therefore
> >    needs a veneer. I think the static linker should resolve this, probably
> >    by emitting a second veneer with the landing pad. Do we know if LLD
> >    gets this right?
> >
> 
> There are two variants here:
> 
> A cross-section call .init.text to .text that spans beyond the 128M range:
> 
> 1a. inside vmlinux, which should be dealt with by the linker, but which might
> be unreliable in practice due to the lack of BTI annotations in asm files,
> missing exec permissions on ELF sections etc. This is addressed by this series,
> but is only an issue for unusually large kernel images (e.g., allyesconfig).

Right, and if we don't care about the >128MB kernel case (I have no idea
if anybody actually uses that big of a kernel?), then we can basically
just drop patches 3-11 in favor of a simple linker assertion (similar to
patches 5 and 6) which just *always* triggers a build error on a large
kernel + BTI + !COMPILE_TEST.

-- 
Josh

  reply	other threads:[~2026-08-16 18:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-15  4:45 [PATCH 00/12] arm64/bti: Fix kernel BTI issues with livepatch, large kernels, toolchains Josh Poimboeuf
2026-08-15  4:45 ` [PATCH 01/12] arm64/bti: Add BTI landing pad to __sdei_asm_handler() Josh Poimboeuf
2026-08-15  5:01   ` sashiko-bot
2026-08-15  4:45 ` [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21 Josh Poimboeuf
2026-08-15  5:00   ` sashiko-bot
2026-08-15  9:56   ` Ard Biesheuvel
2026-08-15 18:57     ` Josh Poimboeuf
2026-08-16  9:41     ` Will Deacon
2026-08-16 13:49       ` Ard Biesheuvel
2026-08-16 18:46         ` Josh Poimboeuf [this message]
2026-08-15  4:45 ` [PATCH 03/12] arm64/bti: Fix BTI linker failures with long branches into .idmap.text Josh Poimboeuf
2026-08-15  4:45 ` [PATCH 04/12] arm64/bti: Work around ld crash caused by linker script aliases Josh Poimboeuf
2026-08-15  4:45 ` [PATCH 05/12] arm64/bti: Add link error for large kernels with BTI and unsupported toolchains Josh Poimboeuf
2026-08-15  4:45 ` [PATCH 06/12] arm64/bti: Add link error for large kernels with BTI and livepatch Josh Poimboeuf
2026-08-15  4:45 ` [PATCH 07/12] arm64/bti: Advertise BTI in assembly objects Josh Poimboeuf
2026-08-15  5:03   ` sashiko-bot
2026-08-15 21:53   ` Mark Brown
2026-08-15  4:45 ` [PATCH 08/12] arm64/bti: Enable BTI in the pi/ startup code Josh Poimboeuf
2026-08-15  4:45 ` [PATCH 09/12] efi/libstub: Preserve the GNU property note Josh Poimboeuf
2026-08-15  4:45 ` [PATCH 10/12] efi/libstub: Remove obsolete .note.gnu.property workaround Josh Poimboeuf
2026-08-15  4:45 ` [PATCH 11/12] arm64/bti: Force-enable BTI linker veneers Josh Poimboeuf
2026-08-15  5:00   ` sashiko-bot
2026-08-15  4:45 ` [PATCH 12/12] arm64/bti: Enable kernel BTI for GCC Josh Poimboeuf

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=aoIEVL0M2QPNIOO3@jpoimboe \
    --to=jpoimboe@kernel.org \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=joe.lawrence@redhat.com \
    --cc=kees@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mbenes@suse.cz \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=pmladek@suse.com \
    --cc=song@kernel.org \
    --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.