linux-kernel - Re: [PATCH v3 0/9] 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: <20251119154834.A-tQsLzh@linutronix.de>
Date: Wed, 19 Nov 2025 16:48:34 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Thomas Weißschuh <linux@...ssschuh.net>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Arnd Bergmann <arnd@...db.de>, Luis Chamberlain <mcgrof@...nel.org>,
	Petr Pavlu <petr.pavlu@...e.com>,
	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>,
	Christophe Leroy <christophe.leroy@...roup.eu>,
	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>,
	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>,
	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 v3 0/9] module: Introduce hash-based integrity checking

On 2025-04-29 10:05:04 [-0400], James Bottomley wrote:
> On Tue, 2025-04-29 at 15:04 +0200, 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,
> 
> I don't believe it does: as long as you know what the key was, which
> you can get from the kernel keyring, you can exactly reproduce the core
> build (it's a public key after all and really equivalent to built in
> configuration).  Is the fact that you have to boot the kernel to get
> the key the problem?  In which case we could insist it be shipped in
> the kernel packaging.

The kernel itself is signed. This is not a problem because distros have
the "unsigned" package which is used for comparison.
The modules are signed by an ephemeral key which is created at build
time. This is where the problem starts:
- the public key is embedded into the kernel. Extracting it with tooling
  is possible (or it is part of the kernel package). Adding this key
  into the build process while rebuilding the kernel should work.
  This will however alter the build process and is not *the* original
  one, which was used to build the image.

- the private key remains unknown which means the modules can not be
  signed. The rebuilding would need to get past this limitation and the
  logic must not be affected by this "change". Then the modules need to
  be stripped of their signature for the comparison.

Doing all this requires additional handling/ tooling on the "validation"
infrastructure. This infrastructure works currently without special
care.
Adding special care will not build the package exactly like it has been
built originally _and_ the results need to be interpreted (as in we
remove this signature and do this and now it is fine).

Adding hashes of each module into the kernel image looks like a
reasonable thing to do. I don't see any downsides to this. Yes, you are
limited to the modules available at build time but this is also the case
today with the ephemeral key. It is meant for distros not for individual
developers testing their code.

With this change it is possible to build a kernel and its modules and
put the result in an archive such as tar/ deb/ rpm. You can build the
package _again_ following exactly the same steps as you did before and
the result will be the identical archive.
Bit by bit.
No need for interpreting the results, stripping signatures or altering
the build process.

I fully agree with this approach. I don't like the big hash array but I
have an idea how to optimize that part. So I don't see a problem in the
long term.

> Regards,
> 
> James

Sebastian