Thread (28 messages) flat view 28 messages, 5 authors, 1d ago

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

From: Sean Christopherson <seanjc@google.com>
Date: 2026-08-12 22:31:36
Also in: linux-modules, lkml

On Wed, Aug 12, 2026, Josh Poimboeuf wrote:
On Wed, Aug 12, 2026 at 10:33:51AM -0700, Sean Christopherson wrote:
quoted
+Dylan

On Sun, Aug 02, 2026, Josh Poimboeuf wrote:
quoted
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 <redacted>
Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
Link: https://lore.kernel.org/20260720145658.1103243-5-joe.lawrence@redhat.com (local)
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 (local)
Thanks much!  After educating myself (a very little bit) on KLP relocs, I think
I even understood all of that!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help