From nobody Mon Sep 28 23:50:55 2026 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 9CF804964F; Sat, 15 Aug 2026 04:45:43 +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=1786769144; cv=none; b=J1bhECUVHGYLN87ehyFvst+/4FDaX2+ADW7cm2gUOWxzR9fG7oilwITT9g6dhBLQzEiCPHncr8DKpwrDtt6KmxJS8gTKhs/HnZkRNmZQEWnt7tyzD8KprnNNPGY8iDTl3vtWmWk8idm6FrvZOiqFc41IfObRVL96Wqe1vlfYq2A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769144; c=relaxed/simple; bh=3M1behHkCGv6bYHhLp39v0ywWcLOIJADqn3UuuMpmQw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YM18Ri9QsgSi40tU+wv+9j3WMb/Wy0wToQ/wFXVKasiggIAFG/FLqTzqXvZl4UphsryQH4U7cy3i5Ib6JD+ivYN3H3E31ZbXo1uAG+KdvHMXfG8bC+QNKRYgxR4ndWZQ48uS5OcSbACV7uUf1SqLhi/dEY6tX78SF58cJApA0G4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nFtaQ7Hy; 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="nFtaQ7Hy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D92991F00ADB; Sat, 15 Aug 2026 04:45:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769143; bh=AHPbfRN1aXc5IcowpP0Zhp7GRqsoacbyPIsxiGgDAIc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=nFtaQ7HynKD0KIr6wOyIrZJDs8M0jhsHT8P2mazfzFwD85V++d7q5LtKKRfqokKs+ xbpmhxxcn7yo71SfMO3QKBccLMWmZYJVsd/pBqwyS3R22O5CcBoVTPJ9jdAeHyN2ry 5sC8e2cQF3vmVW5BWJQw1OUxUoPEmPszo0MJxbhx0f2m3CPy1rwR9PG3ul3OK6VUsU Ldd1FYqKzEKvb+SnUQ8JpjTP5y81t0YTQPc+oXNvQ2jO9/oiR8Dq0c7E+w6A04pPRK S/Qp6BqPFZBOBimSe7O3FXDta/3N7GjL0hYu7PX51uqjDq1a4YqUDSrbvEwEfOoJ3n X4eBHNSyKPgqw== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 01/12] arm64/bti: Add BTI landing pad to __sdei_asm_handler() Date: Fri, 14 Aug 2026 21:45:18 -0700 Message-ID: <99226432cc316215829655c787f71a70f06d1600.1786768375.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" With CONFIG_UNMAP_KERNEL_AT_EL0, __sdei_asm_entry_trampoline() indirect jumps to __sdei_asm_handler(). Add "bti j" to prevent a Branch Target exception. Discovered by code inspection. Fixes: c50d32859e70 ("arm64: Add types to indirect called assembly function= s") Signed-off-by: Josh Poimboeuf --- arch/arm64/kernel/entry.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index e0db14e9c843a..16c21fcb41976 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -976,6 +976,7 @@ NOKPROBE(__sdei_asm_exit_trampoline) * want them. */ SYM_CODE_START(__sdei_asm_handler) + bti j stp x2, x3, [x1, #SDEI_EVENT_INTREGS + S_PC] stp x4, x5, [x1, #SDEI_EVENT_INTREGS + 16 * 2] stp x6, x7, [x1, #SDEI_EVENT_INTREGS + 16 * 3] --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 656BF2E8DEB; Sat, 15 Aug 2026 04:45:44 +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=1786769145; cv=none; b=lbVxIyy1hnQ9hOVU8xuW1JZseDIDwTbj5dYXLZ9V7Nd7/tL5py4TcaHwKi043gAlVNXeawJ99ei5bGNQOFL+tJ9+HKR1+SXi0jXvQdBbD646uv610A2kf9F9YyMjOs9HEFTAuKydZsew+E2cRO5YHCd0T7vJNKDondWWq4MfpFM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769145; c=relaxed/simple; bh=5+2v3xzRRPM2g3ZS5UgEZ+QEO21isz1ppDAGo2uEPMc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UwhYT3/FtpKSCX9j+HIiU3nJZTYzGGyFiOB+29k6iZhNdBOweVditEnVggUmlaLt59J8VY0H3b5e2SnVN72vR3S5RJTyOhR6KFGChk/xLgJhK88aCJ5KzgCLzX027dTpRzT2xPZ33eoQ/1rk9BOQusuxWEIvfh376jN0Uwyog6k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eXcvx5u7; 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="eXcvx5u7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96D691F00ADE; Sat, 15 Aug 2026 04:45:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769144; bh=Nh6+iOz6P0x9Gy9tGfnUR7uYUyFR6FMVvpIxe/ECC8E=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=eXcvx5u77fONLhKjmIiOZseXPxSjRgqbh6+vfvoRJ92yY8GBN4XJLYjLJatsvP9Ts 6IgmA35bg8PJJt5DD3QYgUURx270joU7X+roBR7AfWoqgXJBcrtsdLFu9Di+TPfEy3 24zTxMFe+XPMOWciZB2PrRvGRsPcPGx02DONPb3VoWovtpotahF8l5CAwsDdUFvNHQ VCxKU4L7p3L28IoslkLXlfSKWn+8O6p9341gD/Yv+zNOtuPmZL2UhBPGVdk7qfHhOe GNGDQnfrzY+OjWUxghNT0MKCXQe0G7u07N8c7sK/fIOO0lb90CQR6/qeivzQZf8O/a SQSVTkhmEOB6w== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21 Date: Fri, 14 Aug 2026 21:45:19 -0700 Message-ID: <2ff1b2482406c61ca5979d6284ba5f948a3fbc20.1786768375.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The following BTI exception was seen when loading a livepatch module: Internal error: Oops - BTI: 0000000036000001 [#1] SMP pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=3Djc) pc : kill_orphaned_pgrp+0x0/0x150 lr : do_exit+0x498/0xaf0 [livepatch_combined] The problem is that the patch module's do_exit() is branching to a static function in vmlinux using a module PLT veneer (indirect branch), but the target function doesn't have a BTI landing pad. Clang 21+ omits the landing pad for static functions which can only be reached by a direct branch. But livepatch modules use klp relocations to reference arbitrary kernel symbols, and with CONFIG_RANDOMIZE_MODULE_REGION_FULL the module is far enough away that every call to vmlinux needs a PLT. Note this problem is actually not specific to livepatch. It's possible for any module's .init section to be allocated > 128MB away from its .text section. So calls from .init to .text via a PLT can trigger a BTI exception when the target function doesn't have a landing pad. GCC has always omitted the landing pad when possible, so kernel BTI is already considered incompatible with GCC since commit c0a454b9044f ("arm64/bti: Disable in kernel BTI when cross section thunks are broken"). When missing landing pads are detected, allocate a page close to the target which can be used to hold BTI veneers which receive PLT veneer indirect branches and direct branch to the final target: bti c b Fixes: fd1e0fd71f65 ("arm64: Implement HAVE_LIVEPATCH") Signed-off-by: Josh Poimboeuf --- arch/arm64/include/asm/module.h | 5 + arch/arm64/kernel/module-plts.c | 186 ++++++++++++++++++++++++++++++++ 2 files changed, 191 insertions(+) diff --git a/arch/arm64/include/asm/module.h b/arch/arm64/include/asm/modul= e.h index fb9b88eebeb15..f705cbec4463f 100644 --- a/arch/arm64/include/asm/module.h +++ b/arch/arm64/include/asm/module.h @@ -13,10 +13,15 @@ struct mod_plt_sec { int plt_max_entries; }; =20 +struct bti_veneer_page; + struct mod_arch_specific { struct mod_plt_sec core; struct mod_plt_sec init; =20 + /* for CONFIG_ARM64_BTI_KERNEL */ + struct bti_veneer_page *bti_veneers; + /* for CONFIG_DYNAMIC_FTRACE */ struct plt_entry *ftrace_trampolines; struct plt_entry *init_ftrace_trampolines; diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plt= s.c index 7afd370da9f48..4ba31e336deb6 100644 --- a/arch/arm64/kernel/module-plts.c +++ b/arch/arm64/kernel/module-plts.c @@ -3,12 +3,18 @@ * Copyright (C) 2014-2017 Linaro Ltd. */ =20 +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include #include #include +#include #include +#include +#include +#include =20 static struct plt_entry __get_adrp_add_pair(u64 dst, u64 pc, enum aarch64_insn_register reg) @@ -66,6 +72,180 @@ static bool plt_entries_equal(const struct plt_entry *a, (q + aarch64_insn_adrp_get_offset(le32_to_cpu(b->adrp))); } =20 +/* + * The compiler may omit a function's BTI landing pad if it's a static fun= ction + * with no pointers referencing it. That breaks two cases where a PLT mig= ht be + * needed to call such a function: + * + * 1) module cross-section call (e.g., .init to .text) + * + * 2) livepatch module using a klp relocation + * + * Fix up such cases with a second veneer which lives close to the target. + */ +struct bti_veneer { + __le32 bti_c; + __le32 b; +}; + +struct bti_veneer_page { + struct bti_veneer_page *next; + struct bti_veneer *veneers; + unsigned int used; +}; + +#define BTI_VENEERS_PER_PAGE (PAGE_SIZE / sizeof(struct bti_veneer)) + +static bool plt_target_has_landing_pad(u64 target) +{ + u32 insn; + + if (!system_supports_bti_kernel()) + return true; + + if (aarch64_insn_read((void *)target, &insn)) + return true; + + if (!aarch64_insn_is_hint(insn)) + return false; + + switch (insn & 0xFE0) { + case AARCH64_INSN_HINT_BTIC: + case AARCH64_INSN_HINT_BTIJ: + case AARCH64_INSN_HINT_BTIJC: + case AARCH64_INSN_HINT_PACIASP: + case AARCH64_INSN_HINT_PACIBSP: + return true; + } + + return false; +} + +static void *bti_veneer_vmalloc(u64 start, u64 end, gfp_t gfp) +{ + pgprot_t prot =3D __pgprot(pgprot_val(PAGE_KERNEL_ROX) | PTE_MAYBE_GP); + + return __vmalloc_node_range(PAGE_SIZE, PAGE_SIZE, PAGE_ALIGN(start), + ALIGN_DOWN(end, PAGE_SIZE), gfp, prot, + VM_FLUSH_RESET_PERMS, NUMA_NO_NODE, + __builtin_return_address(0)); +} + +static bool bti_veneer_in_range(const struct bti_veneer *veneer, u64 targe= t) +{ + s64 offset =3D (s64)target - (s64)&veneer->b; + + return offset >=3D -SZ_128M && offset < SZ_128M; +} + +static struct bti_veneer_page *bti_veneer_page_alloc(struct module *mod, + u64 target) +{ + struct bti_veneer_page *page; + void *p; + + /* + * vmalloc allocates at the lowest free address in the given range, so + * try the range above the target first so it will be as close as + * possible, making it more likely to be reusable for other targets in + * the same object. + */ + p =3D bti_veneer_vmalloc(target, target + SZ_128M, + GFP_KERNEL | __GFP_NOWARN); + if (!p) + p =3D bti_veneer_vmalloc(target - SZ_128M, target, + GFP_KERNEL | __GFP_NOWARN); + if (!p) { + pr_err("%s: no address space within branch range of %pS for a BTI veneer= \n", + mod->name, (void *)target); + return NULL; + } + + /* Don't leave unused slots executable */ + aarch64_insn_set(p, AARCH64_BREAK_FAULT, PAGE_SIZE); + + page =3D kzalloc_obj(*page, GFP_KERNEL); + if (!page) { + vfree(p); + return NULL; + } + + page->veneers =3D p; + page->next =3D mod->arch.bti_veneers; + mod->arch.bti_veneers =3D page; + + return page; +} + +static u64 module_emit_bti_veneer(struct module *mod, u64 target) +{ + struct bti_veneer_page *page; + struct bti_veneer *veneer, insns; + u32 insn; + + /* Look for an existing veneer for the target */ + for (page =3D mod->arch.bti_veneers; page; page =3D page->next) { + for (unsigned int i =3D 0; i < page->used; i++) { + s32 offset; + + veneer =3D &page->veneers[i]; + insn =3D le32_to_cpu(veneer->b); + offset =3D aarch64_get_branch_offset(insn); + + if ((u64)&veneer->b + offset =3D=3D target) + return (u64)veneer; + } + } + + /* Look for a free slot in range of the target */ + for (page =3D mod->arch.bti_veneers; page; page =3D page->next) { + if (page->used =3D=3D BTI_VENEERS_PER_PAGE) + continue; + + veneer =3D &page->veneers[page->used]; + if (bti_veneer_in_range(veneer, target)) + goto emit; + } + + page =3D bti_veneer_page_alloc(mod, target); + if (!page) + return 0; + + veneer =3D &page->veneers[0]; + +emit: + insn =3D aarch64_insn_gen_branch_imm((u64)&veneer->b, target, + AARCH64_INSN_BRANCH_NOLINK); + if (WARN_ON(insn =3D=3D AARCH64_BREAK_FAULT)) + return 0; + + insns.bti_c =3D cpu_to_le32(aarch64_insn_gen_hint(AARCH64_INSN_HINT_BTIC)= ); + insns.b =3D cpu_to_le32(insn); + + if (!aarch64_insn_copy(veneer, &insns, sizeof(insns))) { + pr_err("%s: failed to write BTI veneer for %pS\n", + mod->name, (void *)target); + return 0; + } + + page->used++; + + return (u64)veneer; +} + +void module_arch_cleanup(struct module *mod) +{ + struct bti_veneer_page *page, *next; + + for (page =3D mod->arch.bti_veneers; page; page =3D next) { + next =3D page->next; + vfree(page->veneers); + kfree(page); + } + + mod->arch.bti_veneers =3D NULL; +} + u64 module_emit_plt_entry(struct module *mod, Elf64_Shdr *sechdrs, void *loc, const Elf64_Rela *rela, Elf64_Sym *sym) @@ -77,6 +257,12 @@ u64 module_emit_plt_entry(struct module *mod, Elf64_Shd= r *sechdrs, int j =3D i - 1; u64 val =3D sym->st_value + rela->r_addend; =20 + if (!plt_target_has_landing_pad(val)) { + val =3D module_emit_bti_veneer(mod, val); + if (!val) + return 0; + } + if (is_forbidden_offset_for_adrp(&plt[i].adrp)) i++; =20 --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 744193254A9; Sat, 15 Aug 2026 04:45:45 +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=1786769147; cv=none; b=QdKWztl48UDkfLa2J2eaRpVPyhQDs6LcLAVg699AVDAmC5vRrxpzIwCTuhfnC0IBxJbpKFTOfpFK09BNPkWIuVTUeTaOC5bVyGmRXPcYd9ftRPkF7abuW69tHiY34bGmioiKo9JEK3L80KlSCrAp2mByqr1Zq4uYutJHqp80Zqs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769147; c=relaxed/simple; bh=NJZuCdn378zNL5UCofyFBX0P47l0IetFygRwkSK2g/E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hPIyr0HjM8nuFsAdm2OciyMeL8Wug+MVom6VTbiFmqkUmBQShhrY8V23dBPmNofeS76xSLf5AQzbUrA/wpQ3xzv0Ag7edj8gkxZ394LE0C3ul7Epjpk7fFSrXFm4R+GSXoCxiA1SIk7Lcuy61tesbk6LeNS7OCkmH3+2AUBiWlA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jtzxYTp7; 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="jtzxYTp7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 516991F00A3D; Sat, 15 Aug 2026 04:45:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769144; bh=AdWP5M8fepkFBrH2JRckg07b+cTfpP4Tn08yEnDUFpM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=jtzxYTp79rvJ3tknzX5+zQxTKPH9Krwr573PMHQgZmdpOlgg1GNO3F1eDmEWlY6Rr uoFCFPKhT7degHBRC2iEFsXSzeNaWB6mNK5RzFeSxHdY82X7XFH/7P/9XMzziK4nFZ TR4lKjtMB62iLTvWr0SVkW0BrTAvZpw5XZxj5pfAweHVY3J+vXsgyqrBfQN7xnAx27 f7AUPu0KQ99r09GW/ASY+Ur9x9d5CXnehRTfU4/dqsdoxII1oPK6ihz9wsABReEs1D gXjdyOT5UeAOSjZAq/P6iZb7frRN7sdRnfZ8ZYoLAIYmvbITLZwsEBgsTXpBcRkVxT P79oyiedVRzeg== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 03/12] arm64/bti: Fix BTI linker failures with long branches into .idmap.text Date: Fri, 14 Aug 2026 21:45:20 -0700 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On a kernel whose text exceeds the +/128MB direct branch range, the linker inserts veneers. With BTI enabled, the veneers' indirect branch targets need a BTI landing pad, which not all functions have starting with Clang 21 (and for all versions of GCC). In such cases the linker can emit a second veneer close to the target which has the landing pad along with a direct branch to the target. But a long branch to .idmap.text never gets one because it's missing the executable section flag. With the LLVM linker, it's a silent failure, presumably only discovered by a BTI exception at runtime. With the GNU linker it's even worse, as it dereferences the missing stub/veneer group entry and seg faults (this was how I discovered it). Make sure the section is executable by adding the "x" flag to all the creators of the input section. Also manually add "bti c" to primary_entry() and enter_vhe(), otherwise the linker-generated veneer page pushes the .idmap.text past its asserted 4KB size: ld.bfd: ID map text too big or misaligned Link: https://sourceware.org/bugzilla/show_bug.cgi?id=3D34525 Signed-off-by: Josh Poimboeuf --- arch/arm64/kernel/cpu-reset.S | 2 +- arch/arm64/kernel/head.S | 7 ++++--- arch/arm64/kernel/hyp-stub.S | 1 + arch/arm64/kernel/sleep.S | 2 +- arch/arm64/mm/proc.S | 8 ++++---- 5 files changed, 11 insertions(+), 9 deletions(-) diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S index c87445dde6745..9943a7c70f6b0 100644 --- a/arch/arm64/kernel/cpu-reset.S +++ b/arch/arm64/kernel/cpu-reset.S @@ -14,7 +14,7 @@ #include =20 .text -.pushsection .idmap.text, "a" +.pushsection .idmap.text, "ax" =20 /* * cpu_soft_restart(el2_switch, entry, arg0, arg1, arg2) diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 87a822e5c4ca8..541721488bef9 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -71,7 +71,7 @@ =20 __EFI_PE_HEADER =20 - .section ".idmap.text","a" + .section ".idmap.text","ax" =20 /* * The following callee saved general purpose registers are used on the @@ -83,6 +83,7 @@ * x21 primary_entry() .. start_kernel() FDT pointer passe= d at boot in x0 */ SYM_CODE_START(primary_entry) + bti c bl record_mmu_state bl preserve_boot_args =20 @@ -251,7 +252,7 @@ SYM_FUNC_END(__primary_switched) * end early head section, begin head code that is also used for * hotplug and needs to have the same protections as the text region */ - .section ".idmap.text","a" + .section ".idmap.text","ax" =20 /* * Starting from EL2 or EL1, configure the CPU to execute at the highest @@ -455,7 +456,7 @@ SYM_FUNC_END(set_cpu_boot_mode_flag) * Checks if the selected granule size is supported by the CPU. * If it isn't, park the CPU */ - .section ".idmap.text","a" + .section ".idmap.text","ax" SYM_FUNC_START(__enable_mmu) mrs x3, ID_AA64MMFR0_EL1 ubfx x3, x3, #ID_AA64MMFR0_EL1_TGRAN_SHIFT, 4 diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S index 37c6976e44a4c..5f9c5ffb4afc1 100644 --- a/arch/arm64/kernel/hyp-stub.S +++ b/arch/arm64/kernel/hyp-stub.S @@ -167,6 +167,7 @@ SYM_CODE_END(__finalise_el2) .pushsection .idmap.text, "ax" =20 SYM_CODE_START_LOCAL(enter_vhe) + bti c // Invalidate TLBs before enabling the MMU tlbi vmalle1 dsb nsh diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S index f093cdf71be11..dfb5b8bc8cdb5 100644 --- a/arch/arm64/kernel/sleep.S +++ b/arch/arm64/kernel/sleep.S @@ -97,7 +97,7 @@ SYM_FUNC_START(__cpu_suspend_enter) ret SYM_FUNC_END(__cpu_suspend_enter) =20 - .pushsection ".idmap.text", "a" + .pushsection ".idmap.text", "ax" SYM_CODE_START(cpu_resume) mov x0, xzr bl init_kernel_el diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S index 22866b49be372..b8ff93c748bf1 100644 --- a/arch/arm64/mm/proc.S +++ b/arch/arm64/mm/proc.S @@ -175,7 +175,7 @@ alternative_else_nop_endif SYM_FUNC_END(cpu_do_resume) #endif =20 - .pushsection ".idmap.text", "a" + .pushsection ".idmap.text", "ax" =20 .macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2 adrp \tmp1, reserved_pg_dir @@ -211,7 +211,7 @@ SYM_FUNC_ALIAS(__pi_idmap_cpu_replace_ttbr1, idmap_cpu_= replace_ttbr1) #define KPTI_NG_PTE_FLAGS (PTE_ATTRINDX(MT_NORMAL) | PTE_TYPE_PAGE | \ PTE_AF | PTE_SHARED | PTE_UXN | PTE_WRITE) =20 - .pushsection ".idmap.text", "a" + .pushsection ".idmap.text", "ax" =20 .macro pte_to_phys, phys, pte and \phys, \pte, #PTE_ADDR_LOW @@ -438,7 +438,7 @@ SYM_FUNC_END(idmap_kpti_install_ng_mappings) .popsection #endif =20 - .pushsection ".idmap.text", "a" + .pushsection ".idmap.text", "ax" SYM_TYPED_FUNC_START(wait_linear_map_split_to_ptes) /* Must be same registers as in idmap_kpti_install_ng_mappings */ swapper_ttb .req x3 @@ -479,7 +479,7 @@ SYM_FUNC_END(wait_linear_map_split_to_ptes) * Output: * Return in x0 the value of the SCTLR_EL1 register. */ - .pushsection ".idmap.text", "a" + .pushsection ".idmap.text", "ax" SYM_FUNC_START(__cpu_setup) tlbi vmalle1 // Invalidate local TLB dsb nsh --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 C48CA332907; Sat, 15 Aug 2026 04:45:45 +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=1786769147; cv=none; b=sy+16JXdB7OclI7NmAsLKFC5B64AuMjDKvR8IC3KpVo2cUWDYdbY8lCEmol+UWUEGoaOaVAR+q70nRXV8wRst2/qGN8e1phnpYHslmZXXAkjkVYfIhVJMKkwKPSrwR35KXzGUzv5AexRUdAHLKDP0hAenRQu1O8WUSWd+JcsxQI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769147; c=relaxed/simple; bh=dLJSRo+ImHHkg1BkbGUaNAOlpYKzg6/JvG8n8wrWuvs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UtK2kpeAsuQbAUtby1RrwGpIbnPjqE4GFplrHCcjZV7CHiAL1MWPsby7YwkYUcvlhTaOhsktljSTUBj9yptnxxalQSh18PN4FYrcECzHk3M+DAPS3UvJ+yLjeTPovqa/hXYPDF22NgA1yK9CPt7gj2iVNeySTNPghKbhMEK3xQI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VnU50eIP; 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="VnU50eIP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 100591F00A3E; Sat, 15 Aug 2026 04:45:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769145; bh=e/t/Rfxakry9H0AfVxYXBBWUY45B3IiZbJ9hnB5qt+U=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=VnU50eIPWqhBcTlqnV5boRpx4D1n0N4/Yg/CvyWyImvRgu4dUa/MEnSno7Mt6VacA zSPGwvTV/FT9Inn0DXnAxCPzRM2+0Lw0jKODBv243vX2g8yROhA71/klTemO3wrUKx f1bjWol7ViVDCduHhJg6RSLaW0Hb1VOGQhmB4NmiBVrKgrQT+eatYYrQqinDDrv/1E 5iJL69qVjVFg/aUrYZQFQnLzHHph6hsdNko7pu7/fLdMaztBtcVKCwKel6M7SielPM O22SsMSi9J9HD1aon2S2sWklqDTZ3C4sI1ztX3ydWD0PDOy65e0WwvlEn55xFvr4lk Df9ldJDoshMPw== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 04/12] arm64/bti: Work around ld crash caused by linker script aliases Date: Fri, 14 Aug 2026 21:45:21 -0700 Message-ID: <5660aa2639925c936e6e5e2c3a224fc2a63457eb.1786768375.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Linking an allyesconfig kernel (~700MB of text) with the GNU linker and CONFIG_ARM64_BTI_KERNEL triggers a seg fault in the linker: #1 elf64_aarch64_stub_name (input_section=3D0x100000040, sym_sec=3D..., = hash=3D..., rel=3D...) at ../../bfd/elfnn-aarch64.c:3042 #2 _bfd_aarch64_add_call_stub_entries (...) at ../../bfd/elfnn-aarch64.c= :4674 #3 elf64_aarch64_size_stubs (...) at ../../bfd/elfnn-aarch64.c:4839 On a kernel whose text exceeds the +/128MB direct branch range, the linker inserts veneers. With BTI enabled, the veneers' indirect branch targets need a BTI landing pad, which not all functions have starting with Clang 21 (and for all versions of GCC). In such cases the linker can emit a second veneer close to the target which has the landing pad along with a direct branch to the target. The GNU linker assumes each target has an input section. But linker-defined symbols don't have input sections, and ld crashes trying to access their veneer data. vmlinux.lds.S (via image-vars.h) uses PROVIDE() to alias some function symbols into the __efistub_ and __pi_ namespaces, which are used by the EFI stub and the position-independent startup code, respectively. Work around the crash by defining those aliases in code. Note this might also end up being a permanent fix, depending on whether the ld fix ends up reporting an error for such cases, or whether it will infer the alias's section from the aliasee. Define the five affected aliases in the objects which define their aliasees so they live in a real input section. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=3D34525 Signed-off-by: Josh Poimboeuf --- arch/arm64/kernel/head.S | 1 + arch/arm64/kernel/image-vars.h | 13 +------------ arch/arm64/lib/memcpy.S | 3 +++ arch/arm64/lib/memset.S | 2 ++ arch/arm64/mm/cache.S | 1 + 5 files changed, 8 insertions(+), 12 deletions(-) diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 541721488bef9..e96af16b421d8 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -130,6 +130,7 @@ SYM_CODE_START(primary_entry) bl __cpu_setup // initialise processor b __primary_switch SYM_CODE_END(primary_entry) +SYM_FUNC_ALIAS(__efistub_primary_entry, primary_entry) =20 __INIT SYM_CODE_START_LOCAL(record_mmu_state) diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h index d4c7d45ae6bc8..713b96cf5dc89 100644 --- a/arch/arm64/kernel/image-vars.h +++ b/arch/arm64/kernel/image-vars.h @@ -20,19 +20,12 @@ PROVIDE(pisym =3D sym); \ ASSERT((sym - KIMAGE_VADDR) < (__bss_start - KIMAGE_VADDR), #msg) =20 -PROVIDE(__efistub_primary_entry =3D primary_entry); - /* * The EFI stub has its own symbol namespace prefixed by __efistub_, to * isolate it from the kernel proper. The following symbols are legally * accessed by the stub, so provide some aliases to make them accessible. - * Only include data symbols here, or text symbols of functions that are - * guaranteed to be safe when executed at another offset than they were - * linked at. The routines below are all implemented in assembler in a - * position independent manner + * Only include data symbols here. */ -PROVIDE(__efistub_caches_clean_inval_pou =3D __pi_caches_clean_inval_pou); - PROVIDE(__efistub__text =3D _text); PROVIDE(__efistub__end =3D _end); PROVIDE(__efistub___inittext_end =3D __inittext_end); @@ -42,10 +35,6 @@ PROVIDE(__efistub_sysfb_primary_display =3D sysfb_primar= y_display); #endif PROVIDE(__efistub__ctype =3D _ctype); =20 -PROVIDE(__pi___memcpy =3D __pi_memcpy); -PROVIDE(__pi___memmove =3D __pi_memmove); -PROVIDE(__pi___memset =3D __pi_memset); - PI_EXPORT_SYM(id_aa64isar1_override); PI_EXPORT_SYM(id_aa64isar2_override); PI_EXPORT_SYM(id_aa64mmfr0_override); diff --git a/arch/arm64/lib/memcpy.S b/arch/arm64/lib/memcpy.S index 9b99106fb95f1..90dbb0d3acdef 100644 --- a/arch/arm64/lib/memcpy.S +++ b/arch/arm64/lib/memcpy.S @@ -268,3 +268,6 @@ SYM_FUNC_ALIAS(__memmove, __pi_memmove) EXPORT_SYMBOL(__memmove) SYM_FUNC_ALIAS_WEAK(memmove, __memmove) EXPORT_SYMBOL(memmove) + +SYM_FUNC_ALIAS(__pi___memcpy, __pi_memcpy) +SYM_FUNC_ALIAS(__pi___memmove, __pi_memmove) diff --git a/arch/arm64/lib/memset.S b/arch/arm64/lib/memset.S index 97157da65ec6b..31e514f020aa3 100644 --- a/arch/arm64/lib/memset.S +++ b/arch/arm64/lib/memset.S @@ -226,3 +226,5 @@ EXPORT_SYMBOL(__memset) =20 SYM_FUNC_ALIAS_WEAK(memset, __pi_memset) EXPORT_SYMBOL(memset) + +SYM_FUNC_ALIAS(__pi___memset, __pi_memset) diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S index ab75c050f5590..ab2cd6c524073 100644 --- a/arch/arm64/mm/cache.S +++ b/arch/arm64/mm/cache.S @@ -57,6 +57,7 @@ SYM_FUNC_START(caches_clean_inval_pou) ret SYM_FUNC_END(caches_clean_inval_pou) SYM_FUNC_ALIAS(__pi_caches_clean_inval_pou, caches_clean_inval_pou) +SYM_FUNC_ALIAS(__efistub_caches_clean_inval_pou, caches_clean_inval_pou) =20 /* * caches_clean_inval_user_pou(start,end) --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 B0232340403; Sat, 15 Aug 2026 04:45:46 +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=1786769148; cv=none; b=CvmvstKxf47xC+QW4y1Wv3c36pIxet5XazxjTPk2TNauWNjMtg7sB/nMMl5oErNV4Q0ps8ar8KNXlbWR7m2b8Yaq5blW3JXdGPdXDKrfS104KOPD/wcHnhMVLWa3Cdu5JD6+Uzslmu+P8x/hlfnjop3EdOXKY44rYwW+8AEA78k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769148; c=relaxed/simple; bh=4YKEhP3hkDKt0e5ziZtDM+RDAJVHw8pf/nFKS8ENf2c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aqp2pObBXw7DKU4mNJpYnYiirYaWR0TUmLMDjtJDEy3zyORce7A9JMYDwVKA7LjcGw7MQHqsy8jnoQjV2vBMMAw6LAeZmGxgYzc0pR2Gdz80uH93rMVUGw4+rKAw4OQ1RxNZktBseLl9fD9VcvsTmORyoKb2drNeg/RM3DSTooc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UEATv1ut; 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="UEATv1ut" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C86CB1F00A3A; Sat, 15 Aug 2026 04:45:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769146; bh=R3oqNhtnQI75A62nrc5sYJescYksDNsRXLkbblCYMfE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=UEATv1utOClInMq4xd8E4cl9UaZzYIMx4dig53D9/aqDvPh5XkWV36YCQqtyfvKO2 ANe5wOkYtUBbPsD1BaOzq1YD7yYWE2EbkBi4MaoJNWQ1FxjcIEvHe5mFQYVGJjX8en vJ8FN2j5djwmLDO5ywRzrm/ZD0RVgULoSApMTpb9ocdnkQHJ7XoJ+H1qAITAKKTsoF vXM2aaW6iA/YzlayaeSEXLWIMKvPbGluWfH6fhfCxsHHozJjlmw02Cats99vvOSdRW lnk3YN6C+XffzTecYKRp1NxMnJy4Yabs5jBSg8/CbHoE9sbRv9CUU+ilWR0HaOPq9z 9O/dDDc5t+NpA== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 05/12] arm64/bti: Add link error for large kernels with BTI and unsupported toolchains Date: Fri, 14 Aug 2026 21:45:22 -0700 Message-ID: <8932e59a4f6e8383f37078dada1f23639b85a035.1786768375.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On a kernel whose text exceeds the +/128MB direct branch range, the linker inserts veneers. With BTI enabled, the veneers' indirect branch targets need a BTI landing pad, which not all functions have starting with Clang 21 (and for all versions of GCC). In such cases the linker can emit a second veneer close to the target which has the landing pad along with a direct branch to the target. However, that's currently not being done, so GCC and Clang 21+ are broken with BTI on large kernels. Only newer linkers have proper support for adding the second veneer, starting with binutils 2.42 and LLVM 20. Only allow a large kernel with the right combination of compiler and linker. Signed-off-by: Josh Poimboeuf --- arch/arm64/Kconfig | 7 +++++++ arch/arm64/kernel/vmlinux.lds.S | 5 +++++ 2 files changed, 12 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index b3afe0688919b..2687b71438661 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -2123,6 +2123,13 @@ config ARM64_BTI_KERNEL is enabled and the system supports BTI all kernel code including modular code must have BTI enabled. =20 +config CC_OMITS_BTI_LANDING_PADS + def_bool !CC_IS_CLANG || CLANG_VERSION >=3D 210000 + +config LD_HAS_BTI_STUBS + def_bool (LD_IS_BFD && LD_VERSION >=3D 24200) || \ + (LD_IS_LLD && LLD_VERSION >=3D 200000) + config CC_HAS_BRANCH_PROT_PAC_RET_BTI # GCC 9 or later, clang 8 or later def_bool $(cc-option,-mbranch-protection=3Dpac-ret+leaf+bti) diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.ld= s.S index af1d720209764..3a88da9212831 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -414,6 +414,11 @@ ASSERT((__entry_tramp_text_end - __entry_tramp_text_st= art) <=3D 3*PAGE_SIZE, #ifdef CONFIG_KVM ASSERT(__hyp_bss_start =3D=3D __bss_start, "HYP and Host BSS are misaligne= d") #endif + +#if defined(CONFIG_ARM64_BTI_KERNEL) && !defined(CONFIG_COMPILE_TEST) && \ + defined(CONFIG_CC_OMITS_BTI_LANDING_PADS) && !defined(CONFIG_LD_HAS_BT= I_STUBS) +ASSERT(__exittext_end - _text <=3D SZ_128M, "Kernel text too big for BTI") +#endif /* * If padding is applied before .head.text, virt<->phys conversions will f= ail. */ --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 363E634252B; Sat, 15 Aug 2026 04:45:47 +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=1786769148; cv=none; b=kSkBhBbecnGpM1zNCWNEagy7CUuyOx0VnT5RauMX43Rr4IzDk2UjKjsoOar6YNaAuL5I6tKBRcrXJHz8dL/WnfaJ72/F4WDw9Kg+2byqZpls8ez/zn+ZJsltTM+kTmapz9BJkKR8Mb/l1WjKunvcn3maEtvNXKiUWOdqyEzTZ18= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769148; c=relaxed/simple; bh=qya/h/jgm6BKCIUbx5n1BlQ1yPdZlszC93NTlzGn1TI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TwWyRtaZ7x9gQ+uiiSchoC4uUxJnoyURSCqF+J+tTrtIJaGu+7wy2S4UlapQDwP2py4vZ3mwcnxotyfgwwYPezi6//lAK5MKmTdGvw762nDUP6kuHeEfqkJTnlmStnFicV2kDnNJJjhHDQtXSxNk0iFrJQMbQuWyWKK+/8Y66DQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lFh6UQXU; 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="lFh6UQXU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 818D51F000E9; Sat, 15 Aug 2026 04:45:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769147; bh=9wCRQs/DtGwKuk6KFB2dJnmuHFc0uK43X388YUJ5gCg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=lFh6UQXUzmVr9Vh0yo33HvQJWaCYguigFZnKEJ6gy8qQcxVVhEHMrSt3D5nHMBXhj ziSGYXNNHUpWD02KsjtZnxulTClP4rxAmCYvn9vsyiN25thRAJkSix/BPFZZCA3Y4K splzGd/7Y+gu1zAU631JCcwOOeyLGLtmLyUCS/LcxUQ+WZkIwXwuSklVNccvOdcyKS irrARnSVAYrDtQbNlNx9VZy3X7NR31bGM7T54umCH6EOpNSvwUO/nVebNBxIlRFeKL bM164ghDz+oP9T108vpl+4HGurwA56HUFY8dgIcogYbROdMj025CYjK8xwLL5AypzP ZKw+MIJAwi6Og== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 06/12] arm64/bti: Add link error for large kernels with BTI and livepatch Date: Fri, 14 Aug 2026 21:45:23 -0700 Message-ID: <42ba934395666a29186dad1c072381a64712268b.1786768375.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A livepatch module uses klp relocations to reference static functions in vmlinux. If the livepatch module is placed at an address far away from vmlinux, it needs PLT veneers to call those functions. With BTI enabled, the veneers' indirect branch targets need a BTI landing pad, which not all functions have starting with Clang 21 (and for all versions of GCC). In such cases the module loader attempts to allocate a page close to the target for emitting a second veneer which has the landing pad along with a direct branch to the target. That page has to come from either the region below _text or the region above _end, as there's no way to allocate memory in the middle of the vmlinux image. For a target near the end of a >128MB text region there's no address space below _text within branch range at all, leaving only whatever room happens to remain above _end after rodata, data and bss. If the branch target is out of range from any available free pages, the livepatch module load fails with -ENOEXEC and a "no address space within branch range" error. Add an assertion so it fails the build instead. Only count the module region below _text; counting the space above _end would make a text size limit depend on the size of rodata, data and bss, and doesn't help unless text is bigger than the rest of the image. The span is _text to _etext rather than __exittext_end, as init and exit text are freed before any module loads and can't be klp targets. Distro kernels don't seem to come close to hitting the 128MB text mark, so this should hopefully be more of a safety backstop than something people are actually hitting. Signed-off-by: Josh Poimboeuf --- arch/arm64/kernel/vmlinux.lds.S | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.ld= s.S index 3a88da9212831..f5bd5ad24e19f 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -419,6 +419,13 @@ ASSERT(__hyp_bss_start =3D=3D __bss_start, "HYP and Ho= st BSS are misaligned") defined(CONFIG_CC_OMITS_BTI_LANDING_PADS) && !defined(CONFIG_LD_HAS_BT= I_STUBS) ASSERT(__exittext_end - _text <=3D SZ_128M, "Kernel text too big for BTI") #endif + +#if defined(CONFIG_ARM64_BTI_KERNEL) && !defined(CONFIG_COMPILE_TEST) && \ + defined(CONFIG_CC_OMITS_BTI_LANDING_PADS) && defined(CONFIG_LIVEPATCH) +ASSERT(_etext - _text <=3D SZ_128M - PAGE_SIZE, + "Kernel text too big for BTI live patching") +#endif + /* * If padding is applied before .head.text, virt<->phys conversions will f= ail. */ --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 E6E5D344D88; Sat, 15 Aug 2026 04:45:47 +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=1786769150; cv=none; b=dpjhFY4h/J75pvPc0HsF8iPv9oYaNi6S7+Tx/nCAi0XPofs9Veh0fPvmxKbXFelkF0PW8j9AzgGyYE6osZbG7tpUwAEocZ1w5wJLiBgYPxf9x9T4uDQVp9yJkUYxWYa4pmSS+Nw4U4j0aIfCjdbJs/flCoDAE3W6bWfhMSm242w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769150; c=relaxed/simple; bh=wdRfaGtELZxRn8pMt60oHZSVDjgLL1zcsbH1w6GQ/iw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Lse86NfvDbQHves1ASbJBb8RYOl0CUC12ngdnBwhXPCc2T0izpcTUCOFwCRCtoMV6GOqZOKs4eWfRhvIlk2RvBbFN+peeo3M6zgRWNkfQWzfHwE5ZhJeQl5Q0rqg0XL5rswua6wjoYUijNd5hv2908xlwuhP/7yXj+kxwwTraH0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lXBtNNCm; 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="lXBtNNCm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A4671F00A3D; Sat, 15 Aug 2026 04:45:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769147; bh=WMsKe5btLXaq16w0tIqve5iamtKug/aatm/4NhSQJFY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=lXBtNNCmUIamsfGoa63amsX8TWkAPlX4QFni+73i7Dz/68yfSXGk8cT7h8G1iE/Cd FSYtaRzAbNNSJ4d941Yfev42MF9/CIiVsxEJWpL/nUlFePfWSnI+2Iz2apcIRbIsPQ 89egT/aduhm2jT3YCkXb2UpSqcNWkICll7U8NdSIZKtxPFMaB0ycf9IaVBVKFijQ1Y K4K9L47os82FITiBZ27FOcty/U7eHTKWW0YX0c84AppCktJwaWsLyfpxxP5n/gRF1M Mzds1ttWbTJuxmdjZDn/mUUJUj7mRynTszmuJcQSmJ9DtMC7juSk9ro1X40AysDR+6 VWyfLaSPawUWQ== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 07/12] arm64/bti: Advertise BTI in assembly objects Date: Fri, 14 Aug 2026 21:45:24 -0700 Message-ID: <5340f3df281bebc81aad3cd9a7471d95061b4b9d.1786768375.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On a kernel whose text exceeds the +/-128MB direct branch range, the linker inserts veneers. With BTI enabled, the veneers' indirect branch targets need a BTI landing pad, which not all functions have starting with Clang 21 (and for all versions of GCC). In such cases the linker can emit a second veneer close to the target which has the landing pad along with a direct branch to the target. However, that's currently not being done, so GCC and Clang 21+ are broken with BTI on large kernels. The linker only emits the BTI veneer if *all* input objects have GNU_PROPERTY_AARCH64_FEATURE_1_BTI, which is not being done for hand-written asm. Force-include a property note with the BTI bit into every assembly translation unit, which is accurate as SYM_FUNC_START*() already emits a "bti c" landing pad for callable assembly functions. Signed-off-by: Josh Poimboeuf --- arch/arm64/Makefile | 4 ++++ arch/arm64/include/asm/bti-note.h | 32 +++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 arch/arm64/include/asm/bti-note.h diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 6b005c8fef706..4eee721c0b278 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -23,6 +23,10 @@ ifeq ($(CONFIG_ARM64_ERRATUM_843419),y) LDFLAGS_vmlinux +=3D --fix-cortex-a53-843419 endif =20 +ifeq ($(CONFIG_ARM64_BTI_KERNEL),y) +KBUILD_AFLAGS +=3D -include $(srctree)/arch/arm64/include/asm/bti-note.h +endif + cc_has_k_constraint :=3D $(call try-run,echo \ 'int main(void) { \ asm volatile("and w0, w0, %w0" :: "K" (4294967295)); \ diff --git a/arch/arm64/include/asm/bti-note.h b/arch/arm64/include/asm/bti= -note.h new file mode 100644 index 0000000000000..17ef5692987f7 --- /dev/null +++ b/arch/arm64/include/asm/bti-note.h @@ -0,0 +1,32 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Emit a GNU_PROPERTY_AARCH64_FEATURE_1_BTI note. This is force-included= in + * every assembly file so the linker emits BTI veneers for >128MB kernels. + * + * Clang has -mmark-bti-property, but there's no equivalent for GCC/GAS. + * + * Binutils 2.44+ and LLVM 22+ support a much more compact version: + * + * .aeabi_subsection aeabi_feature_and_bits, optional, ULEB128 + * .aeabi_attribute Tag_Feature_BTI, 1 + */ +#ifndef __ASM_BTI_NOTE_H +#define __ASM_BTI_NOTE_H + + .pushsection .note.gnu.property, "a" + .align 3 + .long 2f - 1f + .long 6f - 3f + .long 5 /* NT_GNU_PROPERTY_TYPE_0 */ +1: .string "GNU" +2: + .align 3 +3: .long 0xc0000000 /* GNU_PROPERTY_AARCH64_FEATURE_1_AND */ + .long 5f - 4f +4: .long 1 /* GNU_PROPERTY_AARCH64_FEATURE_1_BTI */ +5: + .align 3 +6: + .popsection + +#endif /* __ASM_BTI_NOTE_H */ --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 A37E726B0A9; Sat, 15 Aug 2026 04:45:48 +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=1786769151; cv=none; b=P6t1KFfct/K2Uq1DILtmYbw4RYTXSZKhT1Z85QdCpC2NkYVGKq8I1qMNjQacblRzj8WCbvT5YbTRE3yFD4qQoahY8pNN+cu7QkmdRPDWyppp94Nz2fdAiP48s50LlGx6K9d8Yu6dJx17j5Y+7sj2bgM5vq/+A8SHG+TEEcXiwRY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769151; c=relaxed/simple; bh=A09Gz/TbCoq2Ti5x0s6Ko+kTzNOkw34ti4/mPVs+PyU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Nb9zhS3dpvLMjguZZ/SBatdk1XnlJy32VX9jswBVvFKQS7/61CH1EnxKjb8DHU9WqY7H1iLT0px8qeo8pNFH1Dw8plhfSSxJCylFOqGRDrx/fWno3ZcVjEI/5KQnvYAfLrtt1PUZ2VKSHPBEQGVlJRVcDQ7psPF0I3ggSKHwpZU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BLDRKPO2; 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="BLDRKPO2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 067411F00A3E; Sat, 15 Aug 2026 04:45:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769148; bh=6LkxS33qnyE/6tqok/ZW8s+G6Ny9jOmY+DYEf5VvPts=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=BLDRKPO2UAIfe9qZWTOKMzIBtGSupsM7I5UNXXkTscXGh4eLgd5aRLRk2KX5Jo9em RqQGPZtUjoVXI7ylHlpW8LzTWmAN5wKggj2aGVJP6BnCloppuw7OTvjLVBQ34sPHb1 m2vlhihI3FNAeccKVL8GKESwDkGqmCdiaXWxmDw/AEETGuZnttpgiKD5Qdrc6Os9Zs OcF2DovHma57YhbyvB5TncHDkq3gL+Yu5z0s+O5bS6Ha5fFIhDmPGIsiwWzeNXC67J ZmDvvdmkEXE067zQSkVAvypdT3TL8RecUiVLt5eOE9rqN0MUaK1UlubbUz9ACME0xT jwox+srVzRe8g== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 08/12] arm64/bti: Enable BTI in the pi/ startup code Date: Fri, 14 Aug 2026 21:45:25 -0700 Message-ID: <5c25e0a625b4d16a6e91e63c8d82e33d8c043d74.1786768375.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The early startup code in kernel/pi/ is built with -mbranch-protection=3Dnone and has its property note stripped, which prevents the linker from generating BTI veneers in >128MB kernels. Unlike the assembly objects, which only lacked the note because SYM_FUNC_START*() already emits the landing pads, pi/ needs the real thing. Some of it runs with the MMU on, where the kernel text is mapped PTE_GP and BTI is enforced: __pi_scs_patch() is called when loading a module, and __pi_map_range() is called from create_idmap(). Add -mbranch-protection=3Dbti. The added "bti c" landing pads execute as NOPs in the startup code wherever BTI isn't implemented or isn't enforced. Also stop stripping the objects' property notes, as the linker only marks the output BTI-compatible if *all* objects advertise it. Keeping the note as-is isn't enough either: --prefix-alloc-sections=3D.init renames it to .init.note.gnu.property, which GNU ld still parses but LLD ignores. Rename it back afterwards so both linkers see it. Signed-off-by: Josh Poimboeuf --- arch/arm64/kernel/pi/Makefile | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/arm64/kernel/pi/Makefile b/arch/arm64/kernel/pi/Makefile index be92d73c25b21..2101d96d754e5 100644 --- a/arch/arm64/kernel/pi/Makefile +++ b/arch/arm64/kernel/pi/Makefile @@ -4,7 +4,7 @@ KBUILD_CFLAGS :=3D $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) -fpie \ -Os -DDISABLE_BRANCH_PROFILING $(DISABLE_KSTACK_ERASE) \ $(DISABLE_LATENT_ENTROPY_PLUGIN) \ - $(call cc-option,-mbranch-protection=3Dnone) \ + $(call cc-option,-mbranch-protection=3Dbti) \ -I$(srctree)/scripts/dtc/libfdt -fno-stack-protector \ -include $(srctree)/include/linux/hidden.h \ -D__DISABLE_EXPORTS -ffreestanding -D__NO_FORTIFY \ @@ -21,11 +21,14 @@ KBUILD_CFLAGS :=3D $(filter-out $(CC_FLAGS_LTO), $(KBUI= LD_CFLAGS)) =20 hostprogs :=3D relacheck =20 +# --prefix-alloc-sections=3D.init also renames .note.gnu.property, which L= LD then +# ignores, dropping the BTI property. Rename it back. quiet_cmd_piobjcopy =3D $(quiet_cmd_objcopy) - cmd_piobjcopy =3D $(cmd_objcopy) && $(obj)/relacheck $(@) $(<) + cmd_piobjcopy =3D $(cmd_objcopy) && \ + $(OBJCOPY) --rename-section .init.note.gnu.property=3D.note.gnu.pr= operty $(@) && \ + $(obj)/relacheck $(@) $(<) =20 -$(obj)/%.pi.o: OBJCOPYFLAGS :=3D --prefix-symbols=3D__pi_ \ - --remove-section=3D.note.gnu.property +$(obj)/%.pi.o: OBJCOPYFLAGS :=3D --prefix-symbols=3D__pi_ $(obj)/%.pi.o: $(obj)/%.o $(obj)/relacheck FORCE $(call if_changed,piobjcopy) =20 --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 60BDA2ED843; Sat, 15 Aug 2026 04:45:49 +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=1786769150; cv=none; b=o4Da2JPRrZGApUnv7UkwzuZLeQVczXjQqOOKYF6cdkThE/VYlP5C/CWhZh57CgfCYRulwE+Bl9oluw9mMSGpUoUyw0vFsA617ucXEpRldZjZIkJTDUEdOnQZY7eTRE8LwmGPSr/eQ1PAwdUVnHZR1XtvgyWeNT1tbedVW708zhQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769150; c=relaxed/simple; bh=LjDQ70UaEYhvY8UBrUQAircCS/5wtHBctyqoau8f6b4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mjrFOhymIoo/dbhfDmUQ2HwKgikgd2Ja4KVaTNwv6jIcqnKcP+dHKOeJmh/lqs7RuZIrEVGPHnKBabX6pRY17sX3hpBEVELRmYCyZKBRYInT5zO0CWT21wjLF+61EEeepAEIlA4PDkJmqqHjxsLn4k2DXvKdR67x3q7iE8EuZ6U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Hj47LVxo; 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="Hj47LVxo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7BBF1F000E9; Sat, 15 Aug 2026 04:45:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769149; bh=fT44iHwShZYqHlrkVVc92252zfcCjw/uJmqte3KuCwo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Hj47LVxoYM8DunlTEHRgvNdzoKlQ7WASQfHhhJxWXwHqpoDHdGy8+S3dlLQrhl38/ 0o4HXCx9MeNuPPOObGDj4hFfRORTpVhf8bLYkjiTwoKbSJSuhCL3/2jkR8GhuqQID5 VX/xhmWTvAlNwYUtWswI/ij5FKVKt7ADbeD9nFzZupC5RNROOcOGlqgwqExuc3ad3l 1x3YhLIQQw76MIKoVvc17QYWvZtRQ1kX6vvOg8tjkzHKYHyqjMS43qtP4sPqpFBYEz 2/Ci+FiD/VvFcpkBSOijf1Xt1/kn98tzhfhxNVRG4AOafoWw9dP9JKfpDV6ndYoXpq qCbdH7LWCgvfA== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 09/12] efi/libstub: Preserve the GNU property note Date: Fri, 14 Aug 2026 21:45:26 -0700 Message-ID: <0445b20df50894615ada70abb1e6238f33c78a2e.1786768375.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" With "-z force-bti" the linker warns (or errors with CONFIG_WERROR) for every libstub object: warning: BTI is required by -z force-bti, but this input object file lack= s the necessary property note. On arm64 the EFI stub is part of vmlinux, so its objects are annotated as __init at the section level by running objcopy with --prefix-alloc-sections=3D.init. That has the side effect of renaming .note.gnu.property to .init.note.gnu.property, which LLD ignores, resulting in the BTI bit getting removed. That's only a problem for toolchains which advertise the branch protection features solely through .note.gnu.property. GCC 16 and Clang 20 also record them in .ARM.attributes, which objcopy leaves alone, but older compilers emit only the note. Rename the section back to its original name so the linker sees it, and so the generic NOTES macro can discard it. objcopy applies --rename-section before --prefix-alloc-sections regardless of their order on the command line, so this needs a second objcopy invocation rather than another flag on the existing one. RISC-V and LoongArch apply the same .init prefix, so key the rename off that rather than on arm64 alone. Neither emits .note.gnu.property today, and renaming a section which isn't present is a no-op, so this changes nothing for them for now, but it prevents a future silent failure mode. The note is still stripped by --remove-section=3D.note.gnu.property, so this change is inert until that section removal goes away in a subsequent patch. Signed-off-by: Josh Poimboeuf --- drivers/firmware/efi/libstub/Makefile | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/l= ibstub/Makefile index 77a2b2d74f3f6..b1c95f69e807d 100644 --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -155,6 +155,12 @@ STUBCOPY_FLAGS-$(CONFIG_LOONGARCH) +=3D --prefix-alloc= -sections=3D.init \ --prefix-symbols=3D__efistub_ STUBCOPY_RELOC-$(CONFIG_LOONGARCH) :=3D R_LARCH_MARK_LA =20 +# --prefix-alloc-sections=3D.init also renames .note.gnu.property, which t= he +# linker then ignores, dropping the branch protection properties. Rename = it +# back on any architecture which applies the prefix. +STUBCOPY_RENAME-y =3D $(if $(findstring --prefix-alloc-sections,$(STUBCOPY= _FLAGS-y)), \ + --rename-section .init.note.gnu.property=3D.note.gnu.property) + $(obj)/%.stub.o: $(obj)/%.o FORCE $(call if_changed,stubcopy) =20 @@ -171,4 +177,5 @@ quiet_cmd_stubcopy =3D STUBCPY $@ echo "$@: absolute symbol references not allowed in the EFI stub" >&2; \ /bin/false; \ fi; \ - $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@ + $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@ \ + $(if $(STUBCOPY_RENAME-y),; $(OBJCOPY) $(STUBCOPY_RENAME-y) $@) --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 6CF522ED843; Sat, 15 Aug 2026 04:45:50 +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=1786769162; cv=none; b=ipL8FImTPOY8LhHMxZNCfUlHp1ZBB5eFcVjY8NQ1aBoElxrvNhlEVf3OdqV6TAGHwRnE4QAqV7oHK3puS/wvUvpnKPOkZ1ewkgWKCcvFoW/VDmYGppjA2Tl8qcDiblCyq/6RVFN5xA6mUkIh8635y/EXm2OPkfvq2lxbJy8UGqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769162; c=relaxed/simple; bh=lKwrcvDZGGHaPIdjQ94SaFakMaUXJBQwBrEFizBKbjc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aMeMtxwaw62TTtOaoktUQO0pN2zySyejZoT6+EGyGSFhnVDhZVGfL6ZftBl/HGRl2b8euHSkIPhgl68H669JGQfABvsWT+p8uRqDoH5g2U4nbaoZ2KuwFAIo9S+S0kAQ8tGbjXTtp1N1WiaAd6VB5PjTlJdw/Acfksv22PdK0jQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EWSVAKHk; 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="EWSVAKHk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE7001F00A3F; Sat, 15 Aug 2026 04:45:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769150; bh=MPvOEc+5lf8H/6sumQoxrEWGP3CaWe5SGGeAIoQ2JNA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=EWSVAKHkynKQFLG14e1B38tQtZLc06S4HFXzg5dSPwZvmr7ljXSJsg++F9olxojRK jNv/cLfF72Mi2740XqAg82Yk4PFoiZx2n6avnLb8vTsAhoorDpgyABHPztmOco/mG4 FBntnAwwbAZkf7O1ngyOM4m+OPqaHSt2LRHzkIHC8YYMIfzPboYMIUySCHMASxrpVV aP7UXvZO4OGscRC3xcjpaOlLsi7TfaQfqwZlJa4SRP7GZ8q/5VJQzL9Hu+OIS/FcF5 aE8UnGVd3ZVd2vhetg5nNEvv1AU3qJY9O1frMp44QsAgVLfeRpTgWbwFL6iFIGQauu kNjRnpjiedOMg== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 10/12] efi/libstub: Remove obsolete .note.gnu.property workaround Date: Fri, 14 Aug 2026 21:45:27 -0700 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit e2179a09ab08 ("efi/libstub: Disable -mbranch-protection") added --remove-section=3D.note.gnu.property to the stub objcopy invocation to work around a Clang bug where the note was emitted for code-less object files even with -mbranch-protection=3Dnone. That was fixed by LLVM commit a48f6079f288 ("[AArch64] Generate .note.gnu.property based on module flags") which was released with Clang 12. The minimum Clang version is now Clang 17, so this workaround is no longer needed. On arm64, the stub also no longer builds with -mbranch-protection=3Dnone, as it has inherited the kernel's flags since commit 8358098b9787 ("arm64: efi: Enable BTI codegen and add PE/COFF annotation"). Remove the workaround. This fixes BTI on arm64, and is a no-op on RISC-V and LoongArch where the vmlinux generic NOTES macro discards it, and the x86 and ARM decompressors discard .note.* explicitly. Signed-off-by: Josh Poimboeuf Reviewed-by: Nick Desaulniers --- drivers/firmware/efi/libstub/Makefile | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/l= ibstub/Makefile index b1c95f69e807d..e18e124a89acf 100644 --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -106,12 +106,6 @@ lib-$(CONFIG_UNACCEPTED_MEMORY) +=3D unaccepted_memory= .o bitmap.o find.o targets :=3D $(lib-y) lib-y :=3D $(patsubst %.o,%.stub.o,$(lib-y)) =20 -# Even when -mbranch-protection=3Dnone is set, Clang will generate a -# .note.gnu.property for code-less object files (like lib/ctype.c), -# so work around this by explicitly removing the unwanted section. -# https://llvm.org/pr46480 -STUBCOPY_FLAGS-y +=3D --remove-section=3D.note.gnu.property - STUBCOPY_RELOC-$(CONFIG_X86_32) :=3D R_386_32 STUBCOPY_RELOC-$(CONFIG_X86_64) :=3D R_X86_64_64 =20 --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 12D09348C77; Sat, 15 Aug 2026 04:45:51 +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=1786769152; cv=none; b=RpOkvGhUBJyY8eXRW/GSYvt6t3jfhtbqyo3rd2+OEm2VTnhUL7huYXAzDmWN53cZAvea0ijkHwqlmHTh26Xo1iJQbG+hMqw96cUjt9BmRvuHqbpf+sY+xMjQk1NBgOrq+0X1iEk/qjI+yDk9rXAsPcSwYeTmnAnT3ngtGJYN4lM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769152; c=relaxed/simple; bh=Qc8dmVi3VPYi3jyIDF7WQ4WF7JOsXyd2qQaCAyX6ZcE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aZk3efCkjOrnGbo4Db0P7oJZk514/wBqt+SbqyhAX1cr36038ZOIMxKN1UpdeZagXHmJhjnGomBZ2ChXksmr4dWmv4UG9qVyRqXUCcGQkvsN2v+WD4cJcJWN/B6MQf7AwVDg1dsaCN8XSM9IsNGU331y2uyEQHdwVnPl4XyKYKc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Yh2lWpvn; 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="Yh2lWpvn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68A381F00A3A; Sat, 15 Aug 2026 04:45:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769151; bh=y3RAP4/V/S2Ka1HZIeZ+MI/MmRFw0KCRbzs9mdx3m/8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Yh2lWpvnhz/fqU5jrXmd7zdXBwN04vdE8Z/rdgzWLKG0vWbPRSF34Y4UJkIZSwTOs S4CkWWnCpBwkjvzo5FcwdusCciF7mOItmOGAPwvIuWuELsPaQOJ8gcLAnu460XMtlo QO2PATvBByJLhdu2UjJ1jhXdjUsQi9BzR61XVcp/Y0VZgDpOkm80/sHY4DCroSkdzW MtvS3EAex7G0Oqsiug7sSJekBehikkGIdr0L2ZpJe0ss1IlPNA70ziImVNr3QlEnYx P7rBvcsr3r2B2TWM/tPLvFq1yVFWnUyh8HFFnVf4g/SCwrGzMEZIX+SXJpQm0bFbY6 QmA21yYigQvIQ== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 11/12] arm64/bti: Force-enable BTI linker veneers Date: Fri, 14 Aug 2026 21:45:28 -0700 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The linker only emits the BTI veneers if *all* input objects have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. All the kernel's objects now advertise it, but if some object stops doing so, BTI veneers silently stop getting created on >128MB kernels, resulting in BTI exceptions at runtime. Force BTI veneers enabled with "-z force-bti" to prevent a single bad object from ruining things. This also emits a warning (or error with CONFIG_WERROR) if any objects are missing the bit. Signed-off-by: Josh Poimboeuf --- arch/arm64/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 4eee721c0b278..d0db9a6766a2f 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -25,6 +25,7 @@ endif =20 ifeq ($(CONFIG_ARM64_BTI_KERNEL),y) KBUILD_AFLAGS +=3D -include $(srctree)/arch/arm64/include/asm/bti-note.h +LDFLAGS_vmlinux +=3D $(call ld-option,-z force-bti) endif =20 cc_has_k_constraint :=3D $(call try-run,echo \ --=20 2.55.0 From nobody Mon Sep 28 23:50:55 2026 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 C0408330676; Sat, 15 Aug 2026 04:45:51 +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=1786769159; cv=none; b=ILhI5vRrhtdMlfoQ57W9O0uN6crropUisQnJnpl5wExOcj/gmg1Lf/28V+aOp2no54Txas4OlWMAoziSDzLpSWjXjGfJ1xmepfvlNEj6GfKt4UVf+hg8l7Yd5lK3JEaIdydgndDzPX+rOlLc4lJ/CSNWcww4lrH/5y60yXATsr8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786769159; c=relaxed/simple; bh=e0rQStexMZ2GxY4wY8mMJZQNTPMCP8H7AcdPcXyqahs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=j16v9VmxRHdYBIYRDdRfN/rVVECapflEoHsn7Az83E8Z6smBdScrLvzms5HVKWLnKLeG0qOMrpdVzeJtOkW7ds7S40Mh0Cgz699Wz9XbFoo7bvMkg3zj4COTbgEpuAmhYatNI6MCPX6BqAwIhPbmvQeoXms/S6WF9eDqZNW5SM0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Uds8CyUo; 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="Uds8CyUo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23EE81F00A3D; Sat, 15 Aug 2026 04:45:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786769151; bh=pEo+RWxb9Cy4x3mJlC/JTMk3aY2wjCClrY8gzFpWMUM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Uds8CyUoF1Yopnalrb3vrGSp1Q4mPilcRNod/8Z5E79NsAJUV7kN6E8KsQiRZiThv txwf0uf0ZhoRGhI+VbfmdzCqZ2te2ok20qQCpr//+LgJRGrSxmYigTtUp4NUlo9+cK 0b21ZzCEfVeRIqBfhkGXXsM6tsR0kUSCfnvC32Kbk6XZmKm5rwjqXUvBe39Gn31Mlm /jN/eykVUsiIJl+rUOCu26NFUJKI8d/OWsZjGbs0LXHuj+YEt4kZTY4gMNgpEjjW9k v4O0wdtksJhj4d4YMMwnXZmM/Io4n48I79x/7xM9kMV8ecYQGd79l+UWbEFRfy55GZ IbSApACY/8QWQ== From: Josh Poimboeuf To: Catalin Marinas , Will Deacon Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, Song Liu , Miroslav Benes , Petr Mladek , Joe Lawrence , Mark Rutland , Mark Brown , Nick Desaulniers , Kees Cook , Nathan Chancellor , linux-toolchains@vger.kernel.org Subject: [PATCH 12/12] arm64/bti: Enable kernel BTI for GCC Date: Fri, 14 Aug 2026 21:45:29 -0700 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit c0a454b9044f ("arm64/bti: Disable in kernel BTI when cross section thunks are broken") disabled in-kernel BTI for GCC because it omits a function's BTI landing pad when it determines that a function can only ever reached by a direct branch. The observed failure was a module whose init text landed far enough from its core text to need a PLT, whose "br x16" then hit a function with no "bti c". Note that behavior isn't GCC-specific: Clang 21 has started ommitting landing pads as well. Now that all the known BTI bugs have been sorted out, re-enable it for GCC. Signed-off-by: Josh Poimboeuf --- arch/arm64/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 2687b71438661..e150807b03016 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=3D94697 depends on !CC_IS_GCC || GCC_VERSION >=3D 100100 - # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106671 - depends on !CC_IS_GCC depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_ARGS) help Build the kernel with Branch Target Identification annotations --=20 2.55.0