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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1ff0f085-fe89-48b4-bae3-559777a56a0d@t-8ch.de>
Date: Sun, 1 Feb 2026 17:22:12 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Mihai-Drosi Câju <mcaju95@...il.com>
Cc: 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

Hi Mihai-Drosi,

thanks for taking an interest into these patches!

On 2026-01-31 09:36:36+0200, Mihai-Drosi Câju 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.
> 
> I think there is a middle ground where the module signing key is generated
> using a key derivation function that has as an input a deterministic value
> on the build host, such as /etc/machine-id . The problem with this approach
> is that only hosts knowing the value will be able to reproduce the build.

The goal is to make the distro kernel packages rebuildable by the
general public. Any involvement of secret values will break this goal.

> Maybe this is a solution to NixOS secret management? Introduce minimal
> impurity as a cryptographic seed and derive the rest of the secrets using
> something like Argon2(seed, key_uuid).

I am not familiar with NixOS and its secret management.
This patchset serves a wider audience.

> There might be another approach to code integrity rather than step-by-step
> reproducibility. One may exploit the very cryptographic primitives that make
> reproducibility hard to ensure that reproducibility is most  likely valid.
> 
> For example, the module signing issue, the build host publishes four artifacts:
> * The source-code
> * The compiled and signed binary
> * The build environment
> * Its public key
> 
> Now, we don't need to sign with the private key to know that building the source
> code using the specific build environment and signing the result with the private
> key will result in the claimed binary. We can just compile and verify with the
> public key.

This could work if the goal is only to verify the reproducibility of a
single, signed-en-bloc artifact. But we also need to handle vmlinux which
contains the corresponding public key. It would need different handling.
We can add some special logic to strip that public key before
comparision. But then vmlinux might be compressed or wrapped in some
other format. Another whole collection of special logic.

(...)


Thomas