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
--
Josh
