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.jpoim...@kernel.org
Thanks much! After educating myself (a very little bit) on KLP relocs, I think
I even understood all of that!
