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

[Josh Poimboeuf <jpoimboe@kernel.org>]

On Wed, Aug 12, 2026 at 10:33:51AM -0700, Sean Christopherson wrote:
> +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?

Indeed, though we approached it from the tooling side, see this (not yet
merged) patched:

  https://lore.kernel.org/fe5a00818e06ec613344d41d5944de054fcd8832.1786138493.git.jpoimboe@kernel.org

-- 
Josh