From nobody Sat Oct 3 03:52:40 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 DBA3C3845DC; Wed, 5 Aug 2026 14:30:06 +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=1785940212; cv=none; b=nk8nUo0FsLA//jfm2pvyHmw/EY+eF1QgxVTf8C/fhztPs6638AVZizFPXUwktKZpaXWcJeh+QUXfFXD7eYiYT50E5dNNxmIflm0FB85wj4cJxKyOKbo4BWmTKTS16q+vf/bi1gX0H0bpo2g8+eVDgyHu7rHA+QolQVx74DIGfUw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785940212; c=relaxed/simple; bh=Hfjnqjg3aVGCVR3Eelcf74WkYAF0rN8IT5jp2O/gNaM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VURTYS/5+UigzklpC3ae995qFnqqve4Fiuhzh6iFE2mg+nwjcvNwDoT5jmHPRDVpJkWKHz14RcIo/L+luwWTWi3I59KSEHKz9wPRW7qRSSRj3tkyhJy43ymTI0mcqPez+GSs1qo0r85au5H8d03+APB1wiW/++to//ZrEgPDyCQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GpuKjjvF; 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="GpuKjjvF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4A191F00A3E; Wed, 5 Aug 2026 14:29:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785940199; bh=uwstzOpG63diSNCrrN4Jkx77zyzWh2lWfcKJfZYHTiE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=GpuKjjvFT4rywePd+RYjeuJX0u+hsb6UoUk+BJ3j1SPn294C/s8wf2Ji9Ac0ualTi c8rskk5h5K+e9CwtyCiVWLGkbhpmE6YZlMEy4XurDvMQqFUDndku4IVlCTxhruLV3o +tu+htyxCX8YaJNMSksdetXRPIyOfaJE+MGlfm7BB2y3xElOXVcdyFcj5qdwQ3zc/w ZMPzN+U5sOtsJ5Yh4kj9Gtf5WInoqNQgCW1Bfz6rjCW0MNWmqvpSbVRezGNZfcpVBB Vmyj73h40CJa5qOfLhvAEg43vNgY+9oNXl9IDhmBt3nsXqmSLqA1vSDqNYvV1J55Zi 2mK7h8wGq7T/A== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Peter Zijlstra , Joe Lawrence , Miroslav Benes , Petr Mladek , Song Liu Subject: [PATCH v2 1/7] objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol symbols Date: Wed, 5 Aug 2026 07:29:38 -0700 Message-ID: <18345294f074bffdf734ee6a523968aa7d64ef33.1785939903.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.54.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" Testing klp-build with arm64 produced the following linker error during the original kernel build: `__notrim.1' referenced in section `.klp.symid' of vmlinux.o: defined in = discarded section `.no_trim_symbol' of vmlinux.o symbol_get() puts a static __notrim[] in .no_trim_symbol, which GCC names __notrim.1, __notrim.2, etc. Two or more built-in translation units calling symbol_get() thus produce duplicate names, resulting in corresponding .klp.symid references which trigger the above error. Add .no_trim_symbol to the discarded section list so its symbols don't get symids. Note this issue is not specific to arm64: it just needs two built-in symbol_get() callers. arm64 trips over it easily because it has KVM always compiled in vmlinux, whereas on x86 it's typically a module. Fixes: 029223d30162 ("objtool/klp: Add .klp.symid for sympos disambiguation= ") Signed-off-by: Josh Poimboeuf Acked-by: Song Liu --- tools/objtool/klp-symid.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/objtool/klp-symid.c b/tools/objtool/klp-symid.c index cf188cdfa6079..21d8708013aba 100644 --- a/tools/objtool/klp-symid.c +++ b/tools/objtool/klp-symid.c @@ -31,6 +31,7 @@ static const char * const discarded_secs[] =3D { ".discard", ".modinfo", + ".no_trim_symbol", "__tracepoint_check", }; =20 --=20 2.54.0 From nobody Sat Oct 3 03:52:40 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 EFE41388E63; Wed, 5 Aug 2026 14:30:03 +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=1785940208; cv=none; b=HwEEUqVqEXr0VcqbJi51BrqbQU0aQ2a7zNqgm1olq4HP10xqzu9ZSa/l86htEvnpRRr03OtSQxwu+PpBr+Q8H4XTfiko4b0KUrso6MQ7CRjbPhH6bsJXYpf3qD651/8QYSmyZgHRSc90XDFOleImvoyeDog3wBrSxvoYgkEX9/U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785940208; c=relaxed/simple; bh=ILuwttoIVxWUv1qsFsJFrVVzm2dt29D07uz9xDZYCF4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XSFvIU1cDyYI0NIAxaT4Yc8WCaUfIdle+Q7FM9newwXQR3b22tPC5G8A16xpzc0LitTwRys+LaB+SSALeRr9LraV08bBPJjZs80zynbUQ7tgcvW9B68m2Dtr3BCKIGvsZP14sIcmvsdTf2OqIH4ezbD9kFE0fq9M7lDnXg4LQVc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WCe+2cW4; 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="WCe+2cW4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B7161F00A3A; Wed, 5 Aug 2026 14:29:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785940199; bh=OfBVF3pFAvjh2J41PP9wPkXf5AOKvy9xNyclzTxwI4c=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=WCe+2cW4Mv2ldIx3cF7ht8nesVRp4jOD+ghwHSMbB/RA4DoYUuSNjN2Yzic4NXwBQ n5YXewza9k7+dkJ68pOlWOy+vRhXAlQe1RMp13KT2wfcq36nzDKNIJI1NiPnc/frcN sz+smoFPe/v7wgCXiOZKHi+pUnIXMhpGCqF9e10/V5PUth7ErvVJE8W3HK0Bx8HoZZ MdCG5wGmiMTU6tscCXdQGJmISVEOAxAsc1hjfqCSileofr1fqfdZ0Zu6imsIpDvozU RWXB/xaXH0yZrXFVRYnsEZPg0C4mjmAtR01oy4kElBSWuPwFVDhzyr/9E/xz8y9lF1 vw11RRJ30PBfQ== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Peter Zijlstra , Joe Lawrence , Miroslav Benes , Petr Mladek , Song Liu Subject: [PATCH v2 2/7] objtool/klp: Fix size of empty special section entries Date: Wed, 5 Aug 2026 07:29:39 -0700 Message-ID: X-Mailer: git-send-email 2.54.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" create_fake_symbols() sizes each ANNOTATE_DATA_SPECIAL entry from the offset of the next annotation, falling back to the end of the section for the last entry. But the last entry is detected by a zero size, which also happens for an *empty* entry: ALTERNATIVE(oldinstr, "", ft) still annotates its zero-length replacement, at the same offset as the next entry's annotation. So every empty replacement gets a fake symbol spanning the entire rest of .altinstr_replacement. That's harmless today only because find_symbol_containing() picks the smaller of two overlapping symbols. Track whether a next annotation was found rather than inferring it from the size. A zero-length fake symbol is fine: find_symbol_containing() skips those, so the properly sized symbol at the same offset still wins. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffin= g object files") Signed-off-by: Josh Poimboeuf Acked-by: Song Liu --- tools/objtool/klp-diff.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c index 492d7a012cffe..11e8f3ddbb0e6 100644 --- a/tools/objtool/klp-diff.c +++ b/tools/objtool/klp-diff.c @@ -1627,6 +1627,7 @@ static int create_fake_symbols(struct elf *elf) for_each_reloc(sec->rsec, reloc) { unsigned long offset, size; struct reloc *next_reloc; + bool last =3D true; =20 if (annotype(elf, sec, reloc) !=3D ANNOTYPE_DATA_SPECIAL) continue; @@ -1641,10 +1642,11 @@ static int create_fake_symbols(struct elf *elf) continue; =20 size =3D reloc_addend(next_reloc) - offset; + last =3D false; break; } =20 - if (!size) + if (last) size =3D sec_size(reloc->sym->sec) - offset; =20 if (create_fake_symbol(elf, reloc->sym->sec, offset, size)) --=20 2.54.0 From nobody Sat Oct 3 03:52:40 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 9A35C38886A; Wed, 5 Aug 2026 14:30:03 +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=1785940212; cv=none; b=nZA/6VBujN5GEsnOXOTgxsSZTNzPqmfttgn096JqrSdrI8ccJ9agkbr5qc5Eef+HvmmJgNEIUMP3SNFOzod8UAqTvDYXrzrJn28shYbnW9f5MnvsHRTjDzwxYBG+DwPb/ATdQQARIie6aswAHBE3sIMxKtU/ki98RnIoAK05ZbI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785940212; c=relaxed/simple; bh=EYNuaF6doaxxQJyOIofIXN8oHkPcU316iaavUCAc9KQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=e7Urwp8Ouf9JwUIgF5LL+ifoUA7R/mvTdGzDiyowZII3mjJjRenVe5z2JfVNBJTZ6M3QKGELLOEp5ZIypIQfL7uvABrKK9shNrG4yAhRD+bKV3xDAAuHq20I80IIGwBRs1vcspG7Ejyc7QkkN6V/g5VX4zGHKDhsLhZMA0WbvKw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=er/NksyN; 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="er/NksyN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8B861F00ACA; Wed, 5 Aug 2026 14:29:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785940200; bh=8C1aQofDV7HsvKHeAFCooZp2csmiOoW6Cpz9YcY4RoM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=er/NksyN5Ta4Z2qymms4Xly4o57Eu5urtHfVV1lHdZP22WqeD0ijqOrMJwc6/q9WA WIEnvNx5oaqh+TdUUtWG8x7dpv7lUAqnF05TK85IPUwCoDibItrnGIiggv2c6EBcVE zUVGGGFKHSzuaFHIrE0MbiaLz0iyzyVsTO1O93D4ebRpy3aOCZB2/juD0J9AjiTKRV J1JXqDZM9HuTop9w+m235cOnG6e/qXREsQXSJU1RORMfLffHfJR80q+4bZr5FnyNVC oAEE6WC5KPBmiFCBjvISgcZV7SQs2DwPodd7awMABOwBLRRSJeH4XxrLhdzc/V1Iyx RoiAlkQgZCOVg== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Peter Zijlstra , Joe Lawrence , Miroslav Benes , Petr Mladek , Song Liu Subject: [PATCH v2 3/7] objtool/klp: Ignore replacement offset of empty x86 alternatives Date: Wed, 5 Aug 2026 07:29:40 -0700 Message-ID: <9f9c0c444e078869f2bceac7ecc72fe7310e188f.1785939903.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.54.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" An x86 alternative with an empty replacement, e.g. the second entry of ALTERNATIVE_2("orig", "repl", ft1, "", ft2) has a replacementlen of zero. Its replacement offset still gets a relocation, but the label it points at is the end of the previous replacement, which is also the beginning of the *next* alternative's replacement. The value is meaningless; get_alt_entry() already ignores it for that reason. klp diff doesn't ignore it. When such an alternative belongs to a changed function, cloning its relocations drags in the unrelated neighboring replacement, along with everything that replacement references. On an x86 clang/lto build an empty alternative in meminfo_proc_show() pulled in the replacement of an alternative in proc_kcore_init(), silently emitting a klp relocation against init text which has long since been freed by the time the patch is applied. Add arch_alt_ignore_new_reloc() and skip such relocations when cloning. This has to be arch specific: on arm64 a zero-length replacement instead identifies an alternative callback, whose replacement offset points at the callback function and must be preserved. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffin= g object files") Signed-off-by: Josh Poimboeuf Acked-by: Song Liu --- tools/objtool/arch/x86/special.c | 27 +++++++++++++++++++++++++ tools/objtool/include/objtool/special.h | 7 +++++++ tools/objtool/klp-diff.c | 6 +++++- 3 files changed, 39 insertions(+), 1 deletion(-) diff --git a/tools/objtool/arch/x86/special.c b/tools/objtool/arch/x86/spec= ial.c index e817a3fff4491..1e84c81bfcd81 100644 --- a/tools/objtool/arch/x86/special.c +++ b/tools/objtool/arch/x86/special.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-or-later #include =20 +#include #include #include #include @@ -9,6 +10,32 @@ /* cpu feature name array generated from cpufeatures.h */ #include "cpu-feature-names.c" =20 +/* + * An alternative with an empty replacement, e.g. the second entry of + * + * ALTERNATIVE_2("orig", "repl", ft1, "", ft2) + * + * still gets a relocation for its replacement offset. But the label it p= oints + * at is the end of the previous entry's replacement, which is also the + * beginning of the *next* entry's replacement. The value is meaningless:= it's + * only ever used with a length of zero. + */ +bool arch_alt_ignore_new_reloc(struct section *sec, unsigned long offset) +{ + unsigned long entry_off; + + if (strcmp(sec->name, ".altinstructions")) + return false; + + entry_off =3D offset - (offset % ALT_ENTRY_SIZE); + + if (offset - entry_off !=3D ALT_NEW_OFFSET) + return false; + + return !*(unsigned char *)(sec->data->d_buf + entry_off + + ALT_NEW_LEN_OFFSET); +} + void arch_handle_alternative(struct special_alt *alt) { static struct special_alt *group, *prev; diff --git a/tools/objtool/include/objtool/special.h b/tools/objtool/includ= e/objtool/special.h index 121c3761899c1..620dbf6cb0e58 100644 --- a/tools/objtool/include/objtool/special.h +++ b/tools/objtool/include/objtool/special.h @@ -32,6 +32,13 @@ int special_get_alts(struct elf *elf, struct list_head *= alts); =20 void arch_handle_alternative(struct special_alt *alt); =20 +/* + * Should the reloc at @offset -- the "new" (replacement) field of a speci= al + * section group entry -- be ignored? The meaning of a zero-length replac= ement + * is arch specific, so the arch decides. + */ +bool arch_alt_ignore_new_reloc(struct section *sec, unsigned long offset); + bool arch_support_alt_relocation(struct special_alt *special_alt, struct instruction *insn, struct reloc *reloc); diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c index 11e8f3ddbb0e6..07cc8e2703260 100644 --- a/tools/objtool/klp-diff.c +++ b/tools/objtool/klp-diff.c @@ -12,7 +12,7 @@ #include #include #include -#include +#include =20 #include #include @@ -1537,6 +1537,10 @@ static int clone_sym_relocs(struct elfs *e, struct s= ymbol *patched_sym) !strcmp(patched_reloc->sym->sec->name, ".altinstr_aux")) continue; =20 + if (arch_alt_ignore_new_reloc(patched_sym->sec, + reloc_offset(patched_reloc))) + continue; + ret =3D convert_reloc_sym(e->patched, patched_reloc); if (ret < 0) { ERROR_FUNC(patched_rsec->base, reloc_offset(patched_reloc), --=20 2.54.0 From nobody Sat Oct 3 03:52:40 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 B861F3515CD; Wed, 5 Aug 2026 14:30:05 +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=1785940212; cv=none; b=JBLB+QNizpX599Ld0L9Pvz2YdFiEv3Y6C18Zhc0qulVp3lArl4oAWF5q3UITNz49+SyXSxgbMinLbBFwbId+oCepil9pfKNpPt2CJaqMbzWHvIrHmJdseOYDmfZ5hLJ+AlL2Sl/K8VUZw5qZ308p11sTCoKkDoOBzC+nyaPKNC4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785940212; c=relaxed/simple; bh=bXKEGCDiURahuIcWqn7gu0B7fl5MuFihQ3kAmjaVRd0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KhMOBC3uVoHyyJojq5bbymImSgtSHDqsSXp+GGli+tA65lphz4OrDjKQL3//iGbYe8h2V29AaOfuG1HzmcT218wEnBN8SWYkR97Gq/D9hynEEMIohqQv/oGcy9r2LqYYdXCbOFp4HUV5XqHS+idOdUbPA7zCw2zs4U4ucLwOuKs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U80BA/RG; 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="U80BA/RG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 921401F00A3F; Wed, 5 Aug 2026 14:30:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785940201; bh=BqeFykBVHZByMoJTH9yxSh/5uI8akOGShaiCSHB7jhk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=U80BA/RGiAXfalmuXtViFIJuTOBIv6/UX1yKW5UCy33YQ0m3b0/ZJvPhz5FRcqc/G 5vPE9GaAQfR76E3i5a5t6GuzzJDy8rPI0clsW6997i+qiw0tlzLD+4yYRSb4EDCFgs Tdhx52B2QldipWPwQl5iWMhE5dIKR5MS9BXBy2/fvP+ab+XVZv3l+feWE6fXwK7D8m xp9tNJd/3trxWCDdx8SIeVNPTciLaV1UDc9AzESUVvQLU6VZjh+xmhFwhQ0IVoyggY W5Lf2X+nHWwj59lLlm8aPfLBKNhY6QwnIVCe9+OUYGAQLVajUyMDbGkx+0hdXPEuXz 9O2udJ3GXu/6g== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Peter Zijlstra , Joe Lawrence , Miroslav Benes , Petr Mladek , Song Liu Subject: [PATCH v2 4/7] objtool/klp: Explicitly disallow patching or referencing init code/data Date: Wed, 5 Aug 2026 07:29:41 -0700 Message-ID: X-Mailer: git-send-email 2.54.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" Explicitly disallow the patching and referencing of init code/data. Otherwise it could potentially introduce some odd edge cases depending on whether the target object's init section has been freed yet (note that the init code still exists in the target module when doing late module patching). Such edge cases include sympos calculation and the patching and/or referencing of non-existent (init-freed) code/data. Not to mention the inherent differences in behavior that occur when the init code is only patched *some* of the time depending on module loading order or kernel config. Signed-off-by: Josh Poimboeuf --- tools/objtool/klp-sympos.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/tools/objtool/klp-sympos.c b/tools/objtool/klp-sympos.c index bbfae516d3395..dfca9dd746812 100644 --- a/tools/objtool/klp-sympos.c +++ b/tools/objtool/klp-sympos.c @@ -367,6 +367,11 @@ static unsigned long find_vmlinux_sympos(struct symbol= *sym) return sympos; } =20 +static bool is_init_sym(struct symbol *sym) +{ + return strstarts(sym->sec->name, ".init"); +} + /* * "sympos" is used by livepatch to disambiguate duplicate symbol names. */ @@ -376,6 +381,11 @@ unsigned long klp_find_sympos(struct elf *elf, struct = symbol *sym) bool has_dup =3D false; struct symbol *s; =20 + if (is_init_sym(sym)) { + ERROR("%s: can't patch or reference init code/data", sym->name); + return ULONG_MAX; + } + if (sym->bind !=3D STB_LOCAL) return 0; =20 --=20 2.54.0 From nobody Sat Oct 3 03:52:40 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 3890037F006; Wed, 5 Aug 2026 14:30:13 +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=1785940218; cv=none; b=N7RrkqmFxNmu2qK2+nPDh4pxSjZGeS6EoVD3GbC7mvQPvbS3WsXqTV/hx0UgeEhHTSif0QCzAtX6E49jfdywVf3bFhDp/UgwMvguk6BfgqsqTYBl4uc8AxM1ioAksinPDpXcBcapS8nHYvx8ZDU0uR/NkxL6AkyayagoEdhdbHs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785940218; c=relaxed/simple; bh=F7T66tTukzip4fOwYqJmTsqHngKkKtvLvr0BdRdbskk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=o/x9rHX8iYor/0NNMC2IljNuooJ1N/uR8GYz+np4ZgAb/3mLxnBnJILAbMZJMKEtT+RMbuVFbg8Rs0J9h8GQuTPLxjZ9E+6emuB/sr4v4KaUj8+TitJZDMOVuTFFqJHfJv6OsIXTD5xf45Sv6xX7o1e7MvQRDmKZe6GYlFJ7xCc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YP1UY0ss; 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="YP1UY0ss" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E8C81F00ACF; Wed, 5 Aug 2026 14:30:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785940201; bh=pf7PkdqsX0tRjfepkpmlOqNdpDamvDu5Itlxqz/dhFY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YP1UY0ssqsdYQ7TXWyLQiTx+T8bEPbNZ/2hwus+ByidHkEW8EWLBP57rq/VjIu6od 4kEX21mDVznghHQa6WwgkKTYrFbPThuOL8Gwvs+Fg/gmzNgR8uYYGbnGYVfl6VjBcT PM5bzeq7EcIwZEoxsfmFhps2QxSIYNp5g3XZdkXrUkbekorP+RqD9qi+sc9Iz3IYBY HZgZxv7ooifKGxItrSm4uawgGJ31JaTu3EX1SE9zc97hSGNUoJ0bo3yTTFRgR25d19 X+GGzGzp9IJc0QwFsGbBNjPG7PsdvsUH4IY9gy0wTSsuAFFqV1BKnnv8ch3JNqSaJF Fbe/Ifc89xJ4w== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Peter Zijlstra , Joe Lawrence , Miroslav Benes , Petr Mladek , Song Liu Subject: [PATCH v2 5/7] objtool/klp: Fix cross-module klp relocation section naming Date: Wed, 5 Aug 2026 07:29:42 -0700 Message-ID: X-Mailer: git-send-email 2.54.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 klp relocation section is .klp.rela.., where objname is the object being patched. klp-build wrongly derives objname from where the referenced symbol lives, not where it's referenced. For a cross-module reference like patched can_isotp code calling can.ko's can_rx_unregister(), that gives .klp.rela.can..text rather than .klp.rela.can_isotp..text. Unless the patch happens to patch can.ko as well, the relocation never gets applied and the call goes off into the weeds. Name the intermediate section __klp_relocs. so post-link can read the patched object's name from there. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffin= g object files") Reported-by: Joe Lawrence Link: https://lore.kernel.org/20260720145658.1103243-2-joe.lawrence@redhat.= com Signed-off-by: Josh Poimboeuf Acked-by: Song Liu --- tools/objtool/include/objtool/klp.h | 10 ++++-- tools/objtool/klp-diff.c | 17 +++++++-- tools/objtool/klp-post-link.c | 53 +++++++++++++++++------------ 3 files changed, 52 insertions(+), 28 deletions(-) diff --git a/tools/objtool/include/objtool/klp.h b/tools/objtool/include/ob= jtool/klp.h index 0118c2c170c3f..646d8e1f12eff 100644 --- a/tools/objtool/include/objtool/klp.h +++ b/tools/objtool/include/objtool/klp.h @@ -14,11 +14,15 @@ #define KLP_FUNCS_SEC ".init.klp_funcs" =20 /* - * __klp_relocs is an intermediate section which are created by klp diff a= nd - * converted into KLP symbols/relas by "objtool klp post-link". This is n= eeded - * to work around the linker, which doesn't preserve SHN_LIVEPATCH or + * __klp_relocs. are intermediate sections which are created by k= lp + * diff and converted into KLP symbols/relas by "objtool klp post-link". = This + * is needed to work around the linker, which doesn't preserve SHN_LIVEPAT= CH or * SHF_RELA_LIVEPATCH, nor does it support having two RELA sections for a * single PROGBITS section. + * + * "objname" is the name of the object being patched ("vmlinux" or a module + * name). post-link uses it to name the resulting + * .klp.rela.objname.section_name sections. */ #define KLP_RELOCS_SEC "__klp_relocs" #define KLP_STRINGS_SEC ".rodata.klp.str1.1" diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c index 07cc8e2703260..91a9562c45a6e 100644 --- a/tools/objtool/klp-diff.c +++ b/tools/objtool/klp-diff.c @@ -1380,8 +1380,8 @@ static int clone_reloc_klp(struct elfs *e, struct rel= oc *patched_reloc, } =20 /* - * Create the __klp_relocs entry. This will be converted to an actual - * KLP rela by "objtool klp post-link". + * Create the __klp_relocs. entry. This will be converted to + * an actual KLP rela by "objtool klp post-link". * * This intermediate step is necessary to prevent corruption by the * linker, which doesn't know how to properly handle two rela sections @@ -1389,7 +1389,18 @@ static int clone_reloc_klp(struct elfs *e, struct re= loc *patched_reloc, */ =20 if (!klp_relocs) { - klp_relocs =3D elf_create_section(e->out, KLP_RELOCS_SEC, 0, + const char *objname =3D find_modname(e); + char sec_name[SEC_NAME_LEN]; + + if (!objname) + return -1; + + /* section format: __klp_relocs.objname */ + if (snprintf_check(sec_name, SEC_NAME_LEN, + KLP_RELOCS_SEC ".%s", objname)) + return -1; + + klp_relocs =3D elf_create_section(e->out, sec_name, 0, 0, SHT_PROGBITS, 8, SHF_ALLOC); if (!klp_relocs) return -1; diff --git a/tools/objtool/klp-post-link.c b/tools/objtool/klp-post-link.c index c013e39957b11..350d20495897b 100644 --- a/tools/objtool/klp-post-link.c +++ b/tools/objtool/klp-post-link.c @@ -19,19 +19,11 @@ #include #include =20 -static int fix_klp_relocs(struct elf *elf) +static int fix_klp_reloc_sec(struct elf *elf, struct section *symtab, + struct section *klp_relocs) { - struct section *symtab, *klp_relocs; - - klp_relocs =3D find_section_by_name(elf, KLP_RELOCS_SEC); - if (!klp_relocs) - return 0; - - symtab =3D find_section_by_name(elf, ".symtab"); - if (!symtab) { - ERROR("missing .symtab"); - return -1; - } + /* section format: __klp_relocs.sec_objname */ + const char *sec_objname =3D klp_relocs->name + strlen(KLP_RELOCS_SEC "."); =20 for (int i =3D 0; i < sec_size(klp_relocs) / sizeof(struct klp_reloc); i+= +) { struct klp_reloc *klp_reloc; @@ -39,7 +31,6 @@ static int fix_klp_relocs(struct elf *elf) struct section *sec, *tmp, *klp_rsec; unsigned long offset; struct reloc *reloc; - char sym_modname[64]; char rsec_name[SEC_NAME_LEN]; u64 addend; struct symbol *sym, *klp_sym; @@ -55,7 +46,7 @@ static int fix_klp_relocs(struct elf *elf) reloc =3D find_reloc_by_dest(elf, klp_relocs, klp_reloc_off + offsetof(struct klp_reloc, offset)); if (!reloc) { - ERROR("malformed " KLP_RELOCS_SEC " section"); + ERROR("malformed %s section", klp_relocs->name); return -1; } =20 @@ -66,17 +57,13 @@ static int fix_klp_relocs(struct elf *elf) reloc =3D find_reloc_by_dest(elf, klp_relocs, klp_reloc_off + offsetof(struct klp_reloc, sym)); if (!reloc) { - ERROR("malformed " KLP_RELOCS_SEC " section"); + ERROR("malformed %s section", klp_relocs->name); return -1; } =20 klp_sym =3D reloc->sym; addend =3D reloc_addend(reloc); =20 - /* symbol format: .klp.sym.modname.sym_name,sympos */ - if (sscanf(klp_sym->name + strlen(KLP_SYM_PREFIX), "%55[^.]", sym_modnam= e) !=3D 1) - ERROR("can't find modname in klp symbol '%s'", klp_sym->name); - /* * Create the KLP rela: */ @@ -84,7 +71,7 @@ static int fix_klp_relocs(struct elf *elf) /* section format: .klp.rela.sec_objname.section_name */ if (snprintf_check(rsec_name, SEC_NAME_LEN, KLP_RELOC_SEC_PREFIX "%s.%s", - sym_modname, sec->name)) + sec_objname, sec->name)) return -1; =20 klp_rsec =3D find_section_by_name(elf, rsec_name); @@ -134,10 +121,32 @@ static int fix_klp_relocs(struct elf *elf) return 0; } =20 +static int fix_klp_relocs(struct elf *elf) +{ + struct section *symtab, *sec; + + symtab =3D find_section_by_name(elf, ".symtab"); + if (!symtab) { + ERROR("missing .symtab"); + return -1; + } + + for_each_sec(elf, sec) { + if (strncmp(sec->name, KLP_RELOCS_SEC ".", + strlen(KLP_RELOCS_SEC "."))) + continue; + + if (fix_klp_reloc_sec(elf, symtab, sec)) + return -1; + } + + return 0; +} + /* * This runs on the livepatch module after all other linking has been done= . It - * converts the intermediate __klp_relocs section into proper KLP relocs t= o be - * processed by livepatch. This needs to run last to avoid linker wreckag= e. + * converts the intermediate __klp_relocs.* sections into proper KLP reloc= s to + * be processed by livepatch. This needs to run last to avoid linker wrec= kage. * Linkers don't tend to handle the "two rela sections for a single base * section" case very well, nor do they appreciate SHN_LIVEPATCH. */ --=20 2.54.0 From nobody Sat Oct 3 03:52:40 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 53A21389114; Wed, 5 Aug 2026 14:30:12 +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=1785940218; cv=none; b=IE5XxLiSXDd4ymVHggifZfLxdITvWKYKQfTy8eQ2Z8NaM11KNLgDoBeN2vWTU6XVEzHsQfu9wtmFZZZgTtJYh8Rx13WRi3odJobNYTq7RoWocuXOR8QlFsbTD6nfNm5Mp5r8atCga/VdJmRO276ePsydfnUM7GPilDgHfTjlGuE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785940218; c=relaxed/simple; bh=riYAtnpzpPVjIRWzy2+QlSS01Zoi9vrEjPpMXhmcKRM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cyF50cNcDv4+ieayxEqL0GsEVgdAB+cpZEB/iJYXHOREsCpji/MQtl352ITIJ151PNFv7AgEO6sttfn3NNa9EtI9LkeS+dOnquBC1nzAVB2RqJEyxpfwHVFJJt+NWcmQWmTUYurA6tXDV13hythwFON1AhViT7Nxxt7SDliFFIk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HwrygccD; 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="HwrygccD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C539F1F00A3D; Wed, 5 Aug 2026 14:30:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785940202; bh=SrcSJAJhHPJIPDseZ87e2905Qnx5EaA+xQVuSA2G/o4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=HwrygccDcwjD3SaLDy0Vu8tMxNtILyXRcCNxX2wPR8uQPrae+raHMDFcYvjXSrRy9 Q+VHWu8LiiMSjTJ9T5pPK3lYf52OGcmasxY5PF/Rl9LteaSz9Zn214JB7Wqo9uPvWn SaxWjaQz5rGgs5g15xOYiWnfmHAa4iNDhIyJ2NQaSaXNnRHTp2KdyX/wnxok6vVo9N QKNEHM15CkHqRB94GhfgEmPVbBcndgO9mPctY8MqfFFabOlOR+cqOhVV9I0884PsXn apZJloiUYUH7QBxab21zxlLglUk+PArKfvHNQsWRPZ8aEzg6GiWFbmqlCUpLzZqufA 6OAsh534HORVw== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Peter Zijlstra , Joe Lawrence , Miroslav Benes , Petr Mladek , Song Liu Subject: [PATCH v2 6/7] objtool/klp: Don't match local symbols against exports Date: Wed, 5 Aug 2026 07:29:43 -0700 Message-ID: X-Mailer: git-send-email 2.54.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" While cloning a reloc, klp diff calls find_export() to determine whether the referenced symbol is exported. That decides whether the reference needs a klp reloc, which object the klp symbol belongs to, and whether the symbol's data needs to be copied into the patch module. But find_export() matches purely on symbol name, so a static function or variable which happens to share its name with an export is mistaken for a reference to that export: - klp_reloc_needed() creates a klp reloc pointing at the exporting module's symbol rather than the local one. For a vmlinux export it skips the klp reloc altogether, leaving a normal reloc which the module loader resolves to the vmlinux symbol. - clone_reloc() treats the symbol as external and clones it without its data, leaving a dangling reference. - validate_special_section_klp_reloc() attributes a static branch or call key to the wrong module, and for a vmlinux export skips the unsupported-key check entirely. Exports are always global, so ignore local symbols in find_export(). Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffin= g object files") Signed-off-by: Josh Poimboeuf Acked-by: Song Liu --- tools/objtool/klp-diff.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c index 91a9562c45a6e..aebe68a401571 100644 --- a/tools/objtool/klp-diff.c +++ b/tools/objtool/klp-diff.c @@ -1101,6 +1101,9 @@ static struct export *find_export(struct symbol *sym) { struct export *export; =20 + if (is_local_sym(sym)) + return NULL; + hash_for_each_possible(exports, export, hash, str_hash(sym->name)) { if (!strcmp(export->sym, sym->name)) return export; --=20 2.54.0 From nobody Sat Oct 3 03:52:40 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 8FB14312803; Wed, 5 Aug 2026 14:30:12 +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=1785940216; cv=none; b=SATXHUzXYonvDvZR7zwmgj+0yRfMvDo8TdJbqn71ZrVbD0xqYyO/VTsM6JhJJb7i1gkUej8j7FqUDLSRf1chgWB2KeZgs9y9V28kBzBX0AeTUz0Vc820yUO/YeatF4YO/a/gpHBLq5IXO6i9q5blNV/1z/8mgkIZvV1msr7TIp4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785940216; c=relaxed/simple; bh=k2CSLOpb9jRX0kQWt/Qp+HM38LFUbJ9TZseoisSRPOE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QtLzKfrBVl9PHcuq82gKITm4FfMaS07jGHUB20PVhMYm2G3WvWcR4zndMEj5FdcQolOX+ghYSxZH77QL5EP3NL8Y4EbVci7EkpzqA4/lsv8Fc8+dEUozk/E2aNuVxdZfV48OgKcE/8WE9xnihsuyWrx6dlQghPEKJ0Y12fPxTA8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NFm3D9bG; 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="NFm3D9bG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5681B1F00AC4; Wed, 5 Aug 2026 14:30:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785940202; bh=QyYPdR0yIjuNe9t+QOkHL5kMxfB4+ozg4Os4es/nRBI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=NFm3D9bG1s3KVrOrjEBGpPKgILwtcXBicWe/0JGGEb+N1tPsEt3v7AapjQur7xmyS GetP0AGUdJXbtz35JoG9oG96tw9cEdcODnHI38j7ds4Hn5RPf3DDQ5O+ZjPIRT6aAh 0dHm7dPMGr3fVnT7Ttf1oOfHDEuxXF1Pp1Ji1HUkR4ov2+q21Zy8nkk31Qbpqh5UIm JXZtdD5SHhygPOZF0QUv5wcng5jFAuMnDtYYiZXpo+Ib5DvUHOVnwtAT/FvNq3npaq eg8H1q0LEDPwcbUnLLiDr8+IdsdWVdhb5lMqor18o/fojsFATB2ynjIsFbt16PFifq JTr2eKGs8Zw4Q== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Peter Zijlstra , Joe Lawrence , Miroslav Benes , Petr Mladek , Song Liu Subject: [PATCH v2 7/7] objtool/klp: Allow new references to module exports Date: Wed, 5 Aug 2026 07:29:44 -0700 Message-ID: X-Mailer: git-send-email 2.54.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" From: Joe Lawrence klp_reloc_needed() returns true for module exports to support late-module patching. However, clone_reloc_klp() unconditionally rejects symbols without a twin (i.e., new references added by the patch), even when the symbol is a known export from Module.symvers. Relax the check: allow new references to exported symbols by only erroring on !twin when there is no export. The export metadata from Module.symvers provides sufficient context to emit the klp-relocation without a twin. For a module export that isn't sufficient on its own though, as the resulting klp relocation will only be resolved at patch-enable time if the exporting module is loaded. If the original (unpatched) module already depends on the exporting module, the dependency is safe: the module loader ensures the dependency is satisfied before the patched module can be loaded, so the klp relocation target will exist. However, if the patch introduces a reference to a module that the original doesn't depend on, there is no such guarantee. The exporting module could be absent or could be unloaded at any time, leading to a relocation failure or use-after-free. So also add a build-time check: when a new symbol reference (no twin) targets a module export, verify that the original module already has at least one UNDEF symbol resolving to that same exporting module. If not, error out with a diagnostic message. Signed-off-by: Joe Lawrence Signed-off-by: Josh Poimboeuf Acked-by: Song Liu --- tools/objtool/klp-diff.c | 35 +++++++++++++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c index aebe68a401571..0314426abcd8d 100644 --- a/tools/objtool/klp-diff.c +++ b/tools/objtool/klp-diff.c @@ -1294,6 +1294,28 @@ static int convert_reloc_sym(struct elf *elf, struct= reloc *reloc) return convert_reloc_secsym_to_sym(elf, reloc); } =20 +/* + * Check if the original module already has a dependency on dep_mod, i.e. = it + * already references at least one export from that module. + */ +static bool has_module_dep(struct elfs *e, const char *dep_mod) +{ + struct symbol *sym; + + for_each_sym(e->orig, sym) { + struct export *exp; + + if (!is_undef_sym(sym) || is_weak_sym(sym)) + continue; + + exp =3D find_export(sym); + if (exp && !strcmp(exp->mod, dep_mod)) + return true; + } + + return false; +} + /* * Convert a regular relocation to a klp relocation (sort of). */ @@ -1313,8 +1335,17 @@ static int clone_reloc_klp(struct elfs *e, struct re= loc *patched_reloc, unsigned long sympos; =20 if (!patched_sym->twin) { - ERROR("unexpected klp reloc for new symbol %s", patched_sym->name); - return -1; + if (!export) { + ERROR("unexpected klp reloc for new symbol %s", patched_sym->name); + return -1; + } + + if (strcmp(export->mod, "vmlinux") && + !has_module_dep(e, export->mod)) { + ERROR("%s: new reference to %s (exported by %s) would create an undecla= red module dependency", + patched_sym->name, export->sym, export->mod); + return -1; + } } =20 /* --=20 2.54.0