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

[Sean Christopherson <seanjc@google.com>]

+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 <bprockno@redhat.com>
> Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
> Link: https://lore.kernel.org/20260720145658.1103243-5-joe.lawrence@redhat.com
> 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
--