linux-kernel - Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <633ddd60-edbf-4072-932e-2d67d2173edd@t-8ch.de>
Date: Tue, 3 Feb 2026 13:59:02 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Petr Pavlu <petr.pavlu@...e.com>
Cc: Nathan Chancellor <nathan@...nel.org>, Arnd Bergmann <arnd@...db.de>, 
	Luis Chamberlain <mcgrof@...nel.org>, Sami Tolvanen <samitolvanen@...gle.com>, 
	Daniel Gomez <da.gomez@...sung.com>, Paul Moore <paul@...l-moore.com>, 
	James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, 
	Jonathan Corbet <corbet@....net>, Madhavan Srinivasan <maddy@...ux.ibm.com>, 
	Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, 
	Naveen N Rao <naveen@...nel.org>, Mimi Zohar <zohar@...ux.ibm.com>, 
	Roberto Sassu <roberto.sassu@...wei.com>, Dmitry Kasatkin <dmitry.kasatkin@...il.com>, 
	Eric Snowberg <eric.snowberg@...cle.com>, Nicolas Schier <nicolas.schier@...ux.dev>, 
	Daniel Gomez <da.gomez@...nel.org>, Aaron Tomlin <atomlin@...mlin.com>, 
	"Christophe Leroy (CS GROUP)" <chleroy@...nel.org>, Nicolas Schier <nsc@...nel.org>, 
	Nicolas Bouchinet <nicolas.bouchinet@....cyber.gouv.fr>, Xiu Jianfeng <xiujianfeng@...wei.com>, 
	Fabian Grünbichler <f.gruenbichler@...xmox.com>, Arnout Engelen <arnout@...t.net>, 
	Mattia Rizzolo <mattia@...reri.org>, kpcyrd <kpcyrd@...hlinux.org>, 
	Christian Heusel <christian@...sel.eu>, Câju Mihai-Drosi <mcaju95@...il.com>, 
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>, linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arch@...r.kernel.org, linux-modules@...r.kernel.org, 
	linux-security-module@...r.kernel.org, linux-doc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, 
	linux-integrity@...r.kernel.org
Subject: Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking

On 2026-02-03 13:19:20+0100, Petr Pavlu wrote:
> On 1/13/26 1:28 PM, Thomas Weißschuh wrote:
> > The current signature-based module integrity checking has some drawbacks
> > in combination with reproducible builds. Either the module signing key
> > is generated at build time, which makes the build unreproducible, or a
> > static signing key is used, which precludes rebuilds by third parties
> > and makes the whole build and packaging process much more complicated.
> > 
> > The goal is to reach bit-for-bit reproducibility. Excluding certain
> > parts of the build output from the reproducibility analysis would be
> > error-prone and force each downstream consumer to introduce new tooling.
> > 
> > Introduce a new mechanism to ensure only well-known modules are loaded
> > by embedding a merkle tree root of all modules built as part of the full
> > kernel build into vmlinux.
> > 
> > Non-builtin modules can be validated as before through signatures.
> > 
> > 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
> > 
> > The PKCS7 format which is used for regular module signatures can not
> > represent Merkle proofs, so a new kind of module signature is
> > introduced. As this signature type is only ever used for builtin
> > modules, no compatibility issues can arise.
> 
> Nit: The description uses the term "builtin modules" in a misleading
> way. Typically, "builtin modules" refers to modules that are linked
> directly into vmlinux. However, this text uses the term to refer to
> loadable modules that are built together with the main kernel image,
> which is something different.

Agreed. I'll go through everything again, to consistently use "in-tree".

(...)

> > +
> > +	while (fgets(line, PATH_MAX, in)) {
> > +		struct file_entry *entry;
> > +
> > +		fh_list = xreallocarray(fh_list, num_files + 1, sizeof(*fh_list));
> 
> It might be useful to not reallocate this array for each file, although
> I don't immediately see that it contributes any significant time to the
> runtime.

The libc implementation should optimize this internally to not actually
grow one elemet at a time. I'd like to keep this as-is.

(...)

Ack to everything else.