From nobody Mon Sep 28 21:55:13 2026 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 EF2B23C5DCD; Mon, 17 Aug 2026 08:59:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786957179; cv=none; b=B1RXAB/LDxTyVPJJMeAGbDfqdbOuJpYlEbGi0JzwI+Sxt47o45SLENgjI7DtMGfXeVOQSNJrQDyKKAjXxWECqKQG44hqX3H6B6PsqRy85OKbvifOtnrs9GRFHKlFVfkZRRj5rPXGVgnJ7CsI4XBRnxUNgCvEvJ0KCAbXmhd39Ng= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786957179; c=relaxed/simple; bh=rVm+2K6/5i1AXNqpec9gcRU03z3Fby2SwL2vh/cqWIM=; h=Date:From:To:Subject:Cc:In-Reply-To:References:MIME-Version: Message-ID:Content-Type; b=LlvL1APrSQ1D7Gdo7ITyEghizUBaIjoHwlXOKtSobWIpT5dFI4zBjSjQznXhDHOzKPszzxRuovL3sWxA0Pdwg2zJUgn6HlKymfPiwBAR4ZbdDau7/834EoZRy38KWcDy6+y2UqJ0kh78hdtdphAH0hIb4hSO1YM9TGhGx3uP13U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=xqkVgGZT; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=W1g/B1ZS; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="xqkVgGZT"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="W1g/B1ZS" Date: Mon, 17 Aug 2026 08:59:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1786957175; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xcgcYUxsyHFPl/cv4Ep4Qa6Bp2R6sx3kdGGU74xi+SY=; b=xqkVgGZT2AIt4O7HGZZC10W1ym8PI+hYdlZ+9yT955xMD94Jf9S4gSQ5UkKGjO9K5o4Vbm 5uJPtGo8+9W+z6jcItWxIVke0j7hhl7QFNYcepr4FL79jJadCWXDmb+XmxEWEbdh8x8yeB 6pV1CrqtQrdH0qxaEwhx95FQAqr+VdbqbGwQySQ7PQBLxvdIlAV599AsSPb4W7X6YESUsH 5Lis2qB7FxN8CS7QF5DvO5t44FiDNqtBdIYcJmOcYQAV5TakFHDImdjIC4n6JswNyO1RV/ RQwK+ospzE1IuC11eDYSysJ+ydJQ5ekkrMZTazGxDQwdtQbh+U/OQf63LnJc+w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1786957175; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xcgcYUxsyHFPl/cv4Ep4Qa6Bp2R6sx3kdGGU74xi+SY=; b=W1g/B1ZS5VYIY9sXMHqsPcLzAR8cQRN1FW7/bBkbQUplF9eh2VwjFMdzcGhLiAIfzmcSRc k9Npu8vooT8gSrDQ== From: "tip-bot2 for Josh Poimboeuf" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: objtool/core] objtool/klp: Fix vmlinux klp relocations for EXPORT_SYMBOL_FOR_MODULES() Cc: Dylan Hatch , Josh Poimboeuf , Ingo Molnar , Song Liu , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <178695717395.1542179.9913555161089158842.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The following commit has been merged into the objtool/core branch of tip: Commit-ID: d8a2860b4a366bfa8acb3d64da2c546ea26d2091 Gitweb: https://git.kernel.org/tip/d8a2860b4a366bfa8acb3d64da2c546ea= 26d2091 Author: Josh Poimboeuf AuthorDate: Fri, 14 Aug 2026 19:36:34 -07:00 Committer: Ingo Molnar CommitterDate: Mon, 17 Aug 2026 10:53:55 +02:00 objtool/klp: Fix vmlinux klp relocations for EXPORT_SYMBOL_FOR_MODULES() When a module function references a vmlinux symbol which is exported with EXPORT_SYMBOL_FOR_MODULES(), a patch to that function needs to use a klp reloc. Currently, livepatch fails to load such a module: livepatch: invalid access to vmlinux symbol 'get_task_policy' from module= -specific livepatch relocation section livepatch: failed to initialize patch 'livepatch_test' for module 'testmo= d' (-22) livepatch: patch 'livepatch_test' failed for module 'testmod', refusing t= o load module 'testmod' klp diff puts all klp relocs in __klp_relocs., so post-link names the section .klp.rela.., which the kernel rejects for vmlinux symbols. Commit 07f14d6af9d77 ("objtool/klp: Fix cross-module klp relocation section naming") changed the meaning of objname in the klp rela section name to be where the referenced symbol is referenced rather than where it lives. That premise only holds for symbols in a module: the relocs get applied when the patched module gets patched, and the module dependency guarantees the referenced module is loaded by then. A vmlinux symbol needs the opposite. It's always resolvable, and it has to be applied when the patch module loads, before the module loader initializes the patch module's special sections, which may reference it. That's why livepatch rejects vmlinux symbols in module-specific sections. Use "vmlinux" as the section objname when the referenced symbol lives in vmlinux. This moves such klp relocs from .klp.rela.kvm..text to .klp.rela.vmlinux..text. Fixes: 07f14d6af9d77 ("objtool/klp: Fix cross-module klp relocation section= naming") Reported-by: Dylan Hatch Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Acked-by: Song Liu Link: https://patch.msgid.link/f8e3b9fae109903a6aafb2a33310e4afdcebf58e.178= 6761327.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/CADBMgpz7iWC0=3Dt=3D_gE-tfvv0mTPq4kg0qQ2zgP= H8DVPE6eQ9Kw@mail.gmail.com --- tools/objtool/include/objtool/klp.h | 5 +++-- tools/objtool/klp-diff.c | 31 ++++++++++++++++++---------- 2 files changed, 23 insertions(+), 13 deletions(-) diff --git a/tools/objtool/include/objtool/klp.h b/tools/objtool/include/ob= jtool/klp.h index 646d8e1..c57775d 100644 --- a/tools/objtool/include/objtool/klp.h +++ b/tools/objtool/include/objtool/klp.h @@ -20,8 +20,9 @@ * 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 + * "objname" is the object whose loading gates the relocation: "vmlinux" f= or + * references to vmlinux symbols, otherwise the name of the module being + * patched. post-link uses it to name the resulting * .klp.rela.objname.section_name sections. */ #define KLP_RELOCS_SEC "__klp_relocs" diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c index a66049e..16681a7 100644 --- a/tools/objtool/klp-diff.c +++ b/tools/objtool/klp-diff.c @@ -1344,13 +1344,14 @@ static int clone_reloc_klp(struct elfs *e, struct r= eloc *patched_reloc, struct section *sec, unsigned long offset, struct export *export) { + const char *sym_modname, *sym_orig_name, *sec_objname; struct symbol *patched_sym =3D patched_reloc->sym; s64 addend =3D reloc_addend(patched_reloc); - const char *sym_modname, *sym_orig_name; - static struct section *klp_relocs; char tombstone_name[SYM_NAME_LEN]; struct symbol *sym, *klp_sym; unsigned long klp_reloc_off; + struct section *klp_relocs; + char sec_name[SEC_NAME_LEN]; char sym_name[SYM_NAME_LEN]; struct klp_reloc klp_reloc; unsigned long sympos; @@ -1441,20 +1442,28 @@ static int clone_reloc_klp(struct elfs *e, struct r= eloc *patched_reloc, * This intermediate step is necessary to prevent corruption by the * linker, which doesn't know how to properly handle two rela sections * applying to the same base section. + * + * The objname decides when the reloc gets applied. A reference to a + * vmlinux symbol goes in the vmlinux section so it gets applied when + * the patch module loads. Everything else goes in the patched + * object's section, applied when the patched module is loaded. */ =20 - if (!klp_relocs) { - const char *objname =3D find_modname(e); - char sec_name[SEC_NAME_LEN]; - - if (!objname) + if (!strcmp(sym_modname, "vmlinux")) { + sec_objname =3D "vmlinux"; + } else { + sec_objname =3D find_modname(e); + if (!sec_objname) return -1; + } =20 - /* section format: __klp_relocs.objname */ - if (snprintf_check(sec_name, SEC_NAME_LEN, - KLP_RELOCS_SEC ".%s", objname)) - return -1; + /* section format: __klp_relocs.objname */ + if (snprintf_check(sec_name, SEC_NAME_LEN, + KLP_RELOCS_SEC ".%s", sec_objname)) + return -1; =20 + klp_relocs =3D find_section_by_name(e->out, sec_name); + if (!klp_relocs) { klp_relocs =3D elf_create_section(e->out, sec_name, 0, 0, SHT_PROGBITS, 8, SHF_ALLOC); if (!klp_relocs)