Linux Modules
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	 live-patching@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	 Joe Lawrence <joe.lawrence@redhat.com>,
	Miroslav Benes <mbenes@suse.cz>, Petr Mladek <pmladek@suse.com>,
	 Song Liu <song@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>,
	Petr Pavlu <petr.pavlu@suse.com>,
	 Daniel Gomez <da.gomez@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	 linux-modules@vger.kernel.org,
	Ben Procknow <bprockno@redhat.com>,
	 Dylan Hatch <dylanbhatch@google.com>
Subject: Re: [PATCH 03/14] objtool/klp: Fix false module dependencies caused by dead relocs
Date: Wed, 12 Aug 2026 15:31:33 -0700	[thread overview]
Message-ID: <anz0Rbiytt0qEH0n@google.com> (raw)
In-Reply-To: <anzW_H5OlQ-MqWjf@jpoimboe>

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

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

  reply	other threads:[~2026-08-12 22:31 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03  3:24 [PATCH 00/14] objtool/klp: sympos/module/alternative/etc fixes Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 01/14] objtool/klp: Fix module name normalization for paths with dots Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 02/14] objtool/klp: Normalize Module.symvers paths to module names Josh Poimboeuf
2026-08-03  3:37   ` sashiko-bot
2026-08-03  5:37     ` Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 03/14] objtool/klp: Fix false module dependencies caused by dead relocs Josh Poimboeuf
2026-08-12 17:33   ` Sean Christopherson
2026-08-12 20:27     ` Josh Poimboeuf
2026-08-12 22:31       ` Sean Christopherson [this message]
2026-08-03  3:24 ` [PATCH 04/14] objtool/klp: Skip hidden directories when finding objects Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 05/14] objtool/klp: Add .klp.symid for sympos disambiguation Josh Poimboeuf
2026-08-03  3:41   ` sashiko-bot
2026-08-03  5:42     ` Josh Poimboeuf
2026-08-12 13:13       ` Puranjay Mohan
2026-08-12 20:22         ` Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 06/14] objtool/klp: Fix symbol resolution for duplicate data symbols Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 07/14] module: Add module_kallsyms_on_each_core_symbol() Josh Poimboeuf
2026-08-03  6:24   ` Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 08/14] objtool/klp,livepatch: Resolve module symbols against core kallsyms Josh Poimboeuf
2026-08-03  3:53   ` sashiko-bot
2026-08-03  6:26   ` Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 09/14] objtool/klp: Fix size of empty special section entries Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 10/14] objtool/klp: Ignore replacement offset of empty x86 alternatives Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 11/14] objtool/klp: Explicitly disallow patching or referencing init code/data Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 12/14] objtool/klp: Fix cross-module klp relocation section naming Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 13/14] objtool/klp: Don't match local symbols against exports Josh Poimboeuf
2026-08-03  3:24 ` [PATCH 14/14] objtool/klp: Allow new references to module exports Josh Poimboeuf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anz0Rbiytt0qEH0n@google.com \
    --to=seanjc@google.com \
    --cc=bprockno@redhat.com \
    --cc=da.gomez@kernel.org \
    --cc=dylanbhatch@google.com \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mcgrof@kernel.org \
    --cc=peterz@infradead.org \
    --cc=petr.pavlu@suse.com \
    --cc=pmladek@suse.com \
    --cc=samitolvanen@google.com \
    --cc=song@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox