From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F10C4199920; Thu, 19 Feb 2026 15:36:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771515393; cv=none; b=R8VgNODAZE0cUyAK5+fppQdmUvKtGDmMWbt+K+sYmCn/SKEAl6C63O3p5rajmvvHf4VTsvEaMT8AHKg7/XJn4YZ+rJzhM6Xfkwixk5lZitcnifATnoZEe5xAKvIz5Ki7qi3wdW9BtYKYRxvb2Xxp6KYFHIaxTZS7nzkRANO4X9I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771515393; c=relaxed/simple; bh=xvGScHjuinZ0ATzJQB4XWDn+7FfGiPuiuds790maVJM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=i7sWn0jm99MR6P+3O/mWsftjTZwxoTw0GUmasEgn2q0BAfoR1us1GepskVekNBO4fI+I6gm8+7g6ZKRhrwtndNTcYaEhw5aIbNQC0qIkucgSwuqKBi5jEMAkbIgTlCxLqKeMwuoP0snYrQ+eK7DtluI3Da4z15eL7e4+At+mWWc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X9Y8eQbd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X9Y8eQbd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1105BC4CEF7; Thu, 19 Feb 2026 15:36:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771515392; bh=xvGScHjuinZ0ATzJQB4XWDn+7FfGiPuiuds790maVJM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=X9Y8eQbdJ27k5PgYNvucYbCou7PyhGWqSaSw5zQ9BMp5TfRnUEdlq6LpQNPShYF5f 5+FQ33fjy0j5phsKwCSp4c7vnv/kHZcBDSSjYmZlxE1Rtj1KPTdsrqJGBOt45xASBq 44TBES2c3aRoJck462y43Jn27YvOo7ETxGA06SfCErH9+rqHx3PFjCIsihwiliYBCg veM9FYkRpCNI2Sz3gH5imjY0d+gVJfxUt6b95uJIf9Q9ucaEOWthJTA5KvIjlhbXNZ UhYdrRsiVZ56wQU95sEc+CesXOgk3pKmiLRxYkB6wDl85KBhED/TFJPanXaK4uOKHr DM1nWzuo7fGxA== Date: Thu, 19 Feb 2026 15:27:56 +0100 From: Nicolas Schier To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Petr Pavlu , Nathan Chancellor , Arnd Bergmann , Luis Chamberlain , Sami Tolvanen , Daniel Gomez , Paul Moore , James Morris , "Serge E. Hallyn" , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Naveen N Rao , Mimi Zohar , Roberto Sassu , Dmitry Kasatkin , Eric Snowberg , Daniel Gomez , Aaron Tomlin , "Christophe Leroy (CS GROUP)" , Nicolas Bouchinet , Xiu Jianfeng , Fabian =?iso-8859-1?Q?Gr=FCnbichler?= , Arnout Engelen , Mattia Rizzolo , kpcyrd , Christian Heusel , =?iso-8859-1?Q?C=E2ju?= Mihai-Drosi , Sebastian Andrzej Siewior , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-modules@vger.kernel.org, linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-integrity@vger.kernel.org Subject: Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking Message-ID: References: <20260113-module-hashes-v4-0-0b932db9b56b@weissschuh.net> <20260113-module-hashes-v4-15-0b932db9b56b@weissschuh.net> <28cf8d51-7530-41d5-a47b-cad5ecabd269@t-8ch.de> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <28cf8d51-7530-41d5-a47b-cad5ecabd269@t-8ch.de> On Tue, Feb 03, 2026 at 01:55:05PM +0100, Thomas Weißschuh wrote: > On 2026-01-30 18:06:20+0100, Petr Pavlu wrote: > > On 1/13/26 1:28 PM, Thomas Weißschuh wrote: > > > Normally the .ko module files depend on a fully built vmlinux to be > > > available for modpost validation and BTF generation. With > > > CONFIG_MODULE_HASHES, vmlinux now depends on the modules > > > to build a merkle tree. This introduces a dependency cycle which is > > > impossible to satisfy. Work around this by building the modules during > > > link-vmlinux.sh, after vmlinux is complete enough for modpost and BTF > > > but before the final module hashes are > > > > I wonder if this dependency cycle could be resolved by utilizing the > > split into vmlinux.unstripped and vmlinux that occurred last year. > > > > The idea is to create the following ordering: vmlinux.unstripped -> > > modules -> vmlinux, and to patch in .module_hashes only when building > > the final vmlinux. > > > > This would require the following: > > * Split scripts/Makefile.vmlinux into two Makefiles, one that builds the > > current vmlinux.unstripped and the second one that builds the final > > vmlinux from it. > > * Modify the top Makefile to recognize vmlinux.unstripped and update the > > BTF generation rule 'modules: vmlinux' to > > 'modules: vmlinux.unstripped'. > > * Add the 'vmlinux: modules' ordering in the top Makefile for > > CONFIG_MODULE_HASHES=y. > > * Remove the patching of vmlinux.unstripped in scripts/link-vmlinux.sh > > and instead move it into scripts/Makefile.vmlinux when running objcopy > > to produce the final vmlinux. > > > > I think this approach has two main advantages: > > * CONFIG_MODULE_HASHES can be made orthogonal to > > CONFIG_DEBUG_INFO_BTF_MODULES. > > * All dependencies are expressed at the Makefile level instead of having > > scripts/link-vmlinux.sh invoke 'make -f Makefile modules'. > > > > Below is a rough prototype that applies on top of this series. It is a > > bit verbose due to the splitting of part of scripts/Makefile.vmlinux > > into scripts/Makefile.vmlinux_unstripped. > > That looks like a feasible alternative. Before adopting it, I'd like to > hear the preference of the kbuild folks. > > > diff --git a/Makefile b/Makefile > > index 841772a5a260..19a3beb82fa7 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1259,7 +1259,7 @@ vmlinux_o: vmlinux.a $(KBUILD_VMLINUX_LIBS) > > vmlinux.o modules.builtin.modinfo modules.builtin: vmlinux_o > > @: > > > > -PHONY += vmlinux > > +PHONY += vmlinux.unstripped vmlinux > > # LDFLAGS_vmlinux in the top Makefile defines linker flags for the top vmlinux, > > # not for decompressors. LDFLAGS_vmlinux in arch/*/boot/compressed/Makefile is > > # unrelated; the decompressors just happen to have the same base name, > > @@ -1270,9 +1270,11 @@ PHONY += vmlinux > > # https://savannah.gnu.org/bugs/?61463 > > # For Make > 4.4, the following simple code will work: > > # vmlinux: private export LDFLAGS_vmlinux := $(LDFLAGS_vmlinux) > > -vmlinux: private _LDFLAGS_vmlinux := $(LDFLAGS_vmlinux) > > -vmlinux: export LDFLAGS_vmlinux = $(_LDFLAGS_vmlinux) > > -vmlinux: vmlinux.o $(KBUILD_LDS) modpost > > +vmlinux.unstripped: private _LDFLAGS_vmlinux := $(LDFLAGS_vmlinux) > > +vmlinux.unstripped: export LDFLAGS_vmlinux = $(_LDFLAGS_vmlinux) > > +vmlinux.unstripped: vmlinux.o $(KBUILD_LDS) modpost > > + $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux_unstripped > > +vmlinux: vmlinux.unstripped > > $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux > > Maybe we could keep them together in a single Makefile, > and instead have different targets in it. > yes, I think so, too. I like the Petr's alternative. Kind regards, Nicolas