From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25E2D423E9B for ; Wed, 12 Aug 2026 22:31:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786573898; cv=none; b=mPzvnURAr5cq64SZa+KzhPF7vFbiW0Rkmej1A68ALJ2Z48mnPgNpTnqTBWCYdiYHRyw18TipAyLwZK92l/uvAGVDc0oFmE5tOL7Q2Cx/GNWI0kiBD0T06sRhmowFTA3ZbGyKTzdlbe9oRztvyr1J9xpqeCvXddyf3N968Ophz64= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786573898; c=relaxed/simple; bh=NCgbA1Nl6htv7Ct5XsBTLJDqXai4MIz8g3kzJINWoo4=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ULCn3YAQJVQuunHpYFbDetfLckcqqG4FwJJu6nt467Ut1uUSDMtnrRI3F4375d7XkQObIWCZd24I/uEKwcl02I4XpzFqioWe9FSYc5vbreaNWadvv6xXFGA4BVmhy7DvONeEPGd2vOjaOu8wEeA+1VOKuVlRdWWd9s4X6Uv+ULE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ZMuj+zvd; arc=none smtp.client-ip=209.85.215.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZMuj+zvd" Received: by mail-pg1-f199.google.com with SMTP id 41be03b00d2f7-cb6cf425e86so208127a12.1 for ; Wed, 12 Aug 2026 15:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786573895; x=1787178695; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=rf33RbOQxtUsb9Ne02ZQYE/IyKd30WKKnCFvHNaI21k=; b=ZMuj+zvdWHFuqEUv8UnaT88fLTuVIE4fLPr4/t0XHr9yz8QGHsLFggGBrpXsK6tHzv eWsDf+zX2DpqZGYsWr8irmPu4D2Ogygt/Ydl7CkEof7YOim4OwdUdbKlq3dzNuom0Y5p 5Pi/faopmDVsL4/oixGdnBYs5vvlJ8QJAGNFqtXj5tzQrrt0vBRyzuFWfu0ywOe20zUn cR3zZmfz8vlvCejXd7yyP3E/QNr/N8i7H6EXUDS51osO0ynfwNpy8TESVlmkrm1ll0OQ j17UtM1q9La+kFVLf9NQsr0ORlNuPRSIhdaSwNYltlt9ak1+gf+ecA/XdlDPC/pYihTe lo6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786573895; x=1787178695; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=rf33RbOQxtUsb9Ne02ZQYE/IyKd30WKKnCFvHNaI21k=; b=PSJ1g/tXrQ2zGaJJGBeunCOmSexB0hEpNvVgLYDg4HDyisgLlL7R3ZOtK2cb4Ed27j u7kdzbiBS4Vlmi/cdS9agXUYixX27ES0Y+UNdFdPD/kZY0i9/IPw6e6HYU3MuRniEpKQ awBv8AQAGgAguByKekgfbsCi6FHjKoeNqv9apPIJObTi75wPq5vHLrY2JZUwlQq1X2dm p9O9giFqNVenyVrd3INXI7nrQKYfAQTYzPBemevGFbFLU3Mc73LPR3WqBvy9hytzT1rC yOopUtU69suaDdSsCjfd7nyv64XzEEYj3/Em4e0jHzZLiZpTLsPlQxXOElMqQcANs90S YaCQ== X-Forwarded-Encrypted: i=1; AHgh+Rrj+XSvgG0w0gaL2AQi8luTdG6eK0T6lFZss6QErgThb84vwonSGXqWJRGo4d5bgvgau1uQOxkgV1EEqSs=@vger.kernel.org X-Gm-Message-State: AOJu0Yxt0WjqVQ4gaXeCjpkvnHgan3ROkORbn6iu/eoGacW55islnp4c mKeSPjU5nIwpR22E42xhYK04yLVbpj9BDNXR9fQA56pnJLaRp12bCe/OENasWEN7Wz5xJBF5VyQ Wc+jlzQ== X-Received: from pgbfp7.prod.google.com ([2002:a05:6a02:2ce7:b0:c86:5f41:8c94]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:989f:b0:3c1:b9c:4890 with SMTP id adf61e73a8af0-3cc55244655mr1599108637.22.1786573894658; Wed, 12 Aug 2026 15:31:34 -0700 (PDT) Date: Wed, 12 Aug 2026 15:31:33 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <9548393f4d89ec3b498f4f69aa6ef6b9bb7150fe.1785727106.git.jpoimboe@kernel.org> Message-ID: Subject: Re: [PATCH 03/14] objtool/klp: Fix false module dependencies caused by dead relocs From: Sean Christopherson To: Josh Poimboeuf Cc: x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Peter Zijlstra , Joe Lawrence , Miroslav Benes , Petr Mladek , Song Liu , Luis Chamberlain , Petr Pavlu , Daniel Gomez , Sami Tolvanen , linux-modules@vger.kernel.org, Ben Procknow , Dylan Hatch Content-Type: text/plain; charset="us-ascii" 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." so > > > modpost no longer recognizes them. > > > > > > Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") > > > Reported-by: Ben Procknow > > > Reported-by: Joe Lawrence > > > Link: https://lore.kernel.org/20260720145658.1103243-5-joe.lawrence@redhat.com > > > Signed-off-by: Josh Poimboeuf > > > --- > > > 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!