linux-kernel - Re: [PATCH v4 00/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 for Android: free password hash cracker in your pocket

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

Message-ID: <20260201201218.GA15755@quark>
Date: Sun, 1 Feb 2026 12:12:18 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: =?UTF-8?q?Mihai-Drosi=20C=C3=A2ju?= <mcaju95@...il.com>,
	linux@...ssschuh.net, arnd@...db.de, arnout@...t.net,
	atomlin@...mlin.com, bigeasy@...utronix.de, chleroy@...nel.org,
	christian@...sel.eu, corbet@....net, coxu@...hat.com,
	da.gomez@...nel.org, da.gomez@...sung.com,
	dmitry.kasatkin@...il.com, eric.snowberg@...cle.com,
	f.gruenbichler@...xmox.com, jmorris@...ei.org, kpcyrd@...hlinux.org,
	linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-integrity@...r.kernel.org, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-modules@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, lkp@...el.com, maddy@...ux.ibm.com,
	mattia@...reri.org, mcgrof@...nel.org, mpe@...erman.id.au,
	nathan@...nel.org, naveen@...nel.org,
	nicolas.bouchinet@....cyber.gouv.fr, nicolas.schier@...ux.dev,
	npiggin@...il.com, nsc@...nel.org, paul@...l-moore.com,
	petr.pavlu@...e.com, roberto.sassu@...wei.com,
	samitolvanen@...gle.com, serge@...lyn.com, xiujianfeng@...wei.com,
	zohar@...ux.ibm.com
Subject: Re: [PATCH v4 00/17] module: Introduce hash-based integrity checking

On Sun, Feb 01, 2026 at 05:09:48PM +0000, David Howells wrote:
> Mihai-Drosi Câju <mcaju95@...il.com> 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.
> 
> There is another issue too: If you have a static private key that you use to
> sign modules (and probably other things), someone will likely give you a GPL
> request to get it.
> 
> One advantage of using a transient key every build and deleting it after is
> that no one has the key.
> 
> One other thing to remember: security is *meant* to get in the way.  That's
> the whole point of it.
> 
> However, IANAL.
> 
> David

It sounds like hash-based module authentication is just better, then.
If the full set of authentic modules is known at kernel build time, then
signatures are unnecessary to verify their authenticity: a list of
hashes built into the kernel image is perfectly sufficient.

(This patchset actually gets a little fancy and makes it a Merkle tree
root.  But it could be simplified to just a list of hashes.)

With that being the case, why is there still effort being put into
adding more features to module signing?  I would think efforts should be
focused on hash-based module authentication, i.e. this patchset.

- Eric