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

On Wed, Aug 12, 2026, Josh Poimboeuf wrote:
> 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 <[email protected]>
> > > Reported-by: Joe Lawrence <[email protected]>
> > > Link: https://lore.kernel.org/[email protected]
> > > Signed-off-by: Josh Poimboeuf <[email protected]>
> > > ---
> > >  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

Thanks much!  After educating myself (a very little bit) on KLP relocs, I think
I even understood all of that!