Thread (28 messages) flat view 28 messages, 5 authors, 3d ago

Re: [PATCH 03/14] objtool/klp: Fix false module dependencies caused by dead relocs

From: Sean Christopherson <seanjc@google.com>
Date: 2026-08-12 17:33:53
Also in: live-patching, lkml
Subsystem: module support, the rest · Maintainers: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen, Linus Torvalds

+Dylan

On Sun, Aug 02, 2026, Josh Poimboeuf wrote:
When creating a klp reloc, klp-diff keeps the original relocation but
converts the referenced symbol to an UNDEF/WEAK placeholder tombstone
symbol, which gets fully disabled later by klp post-link.  The tombstone
symbol is only needed to avoid confusing objtool when it does the final
run on the patch module.

However, for references to exported symbols, modpost sees the reference
to the tombstone symbol as a real reference to an exported symbol,
resulting in a false module dependency getting created.

Further, for a reference to a tombstone symbol which is exported into a
module namespace, e.g. via EXPORT_SYMBOL_FOR_KVM_INTERNAL(), modpost
can't satisfy the dependency, resulting in a warning like the following:

  module ... uses symbol kvm_flush_remote_tlbs from namespace
  module:kvm-amd,kvm-intel, but does not import it.

Rename the placeholder tombstone symbols to ".klp.tombstone.<name>" so
modpost no longer recognizes them.

Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Reported-by: Ben Procknow <redacted>
Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
Link: https://lore.kernel.org/20260720145658.1103243-5-joe.lawrence@redhat.com (local)
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 tools/objtool/elf.c                 | 13 +++++++++++++
 tools/objtool/include/objtool/klp.h |  2 ++
 tools/objtool/klp-diff.c            | 16 ++++++++++++----
 3 files changed, 27 insertions(+), 4 deletions(-)
Naive question(s) incoming...

How does livepatching deal with the kernel's restrictions around module-specific
namespaces/exports?  AIUI, klp builds a livepatch module, and then loading the
resulting livepatch.ko (or whatever its called) performs the actual patching of
the kernel.  If a patched function in livepatch.ko references an module-specific
exported symbol, how does it actually resolve that symbol?

AFAICT, livepatch.ko would need to explicitly import the module namespace, but
then it would run afoul of setup_modinfo()'s checks that a module isn't explicitly
importing a module namespace.

E.g. if (not-so-hypothetically) one were to try to livepatch
nested_vmx_enter_non_root_mode(), how would livepatch.ko get at things like
kvm_service_local_tlb_flush_requests() and kvm_spurious_fault() without also
creating copies of those functions?  Wouldn't the kernel need something like the
below to exempt livepatch modules from the restriction?

--
From: Sean Christopherson <seanjc@google.com>
Date: Mon, 10 Aug 2026 14:27:50 -0700
Subject: [PATCH] module: Allow livepatch modules to import module-specific
 namespaces

Allow livepatch modules to explicitly import module-specific namespaces,
i.e. to use symbols that were exported for select module(s), as disallowing
use of module-specific exports cripples the ability to livepatch the target
modules.

KVM x86 heavily uses module-specific exports to restrict KVM-internal
exports to KVM's own sub-modules, e.g. kvm-{amd,intel}.ko on x86, and to
restrict a variety of "dangerous" kernel exports that exists purely to
support KVM.  See commits 20c489205836 ("KVM: Export KVM-internal symbols
for sub-modules only") and 6276c67f2bc4 ("x86: Restrict KVM-induced symbol
exports to KVM modules where obvious/possible").

Preventing livepatch modules from using those exports makes it infeasible
to livepatch huge swaths of KVM, even if the to-be-livepatched function
itself is generally compatible with livepatching, to the point where KVM is
effectively un-livepatchable as the most interesting/critical flows in KVM
vendor code rely on functionality provided by the kernel and/or kvm.ko.

Exempting livepatch modules isn't exactly ideal, as it allows circumventing
the "no explicit module-specific imports" rule by using MODULE_INFO() to
tag an arbitrary module as a livepatch module.  However, that's only viable
on kernels built with CONFIG_LIVEPATCH=y, and loading such a module also
taints the kernel.

Fixes: 520b1a147d91 ("module: Add module specific symbol namespace support")
Cc: stable@vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 kernel/module/main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 46dd8d25a605..67181c768af0 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -1823,9 +1823,10 @@ static int setup_modinfo(struct module *mod, struct load_info *info)
 	for_each_modinfo_entry(imported_namespace, info, "import_ns") {
 		/*
 		 * 'module:' prefixed namespaces are implicit, disallow
-		 * explicit imports.
+		 * explicit imports, except for livepatching.
 		 */
-		if (strstarts(imported_namespace, "module:")) {
+		if (!is_livepatch_module(mod) &&
+		    strstarts(imported_namespace, "module:")) {
 			pr_err("%s: module tries to import module namespace: %s\n",
 			       mod->name, imported_namespace);
 			return -EPERM;
base-commit: d58772d8520c7ef247c4b95c9bd76d3a25da9ff5
-- 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help