Message-ID: <840b0334-71e4-45b1-80b0-e883586ba05c@t-8ch.de>
Date: Fri, 2 May 2025 08:53:09 +0200
From: Thomas Weißschuh <linux@...ssschuh.net>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: 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

Hi James,

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.

See below.

> >  or a static key is used, which precludes rebuilds by third parties
> > and makes the whole build and packaging process much more
> > complicated. 
> 
> No, it's the same as above ... as long as you have the public key you
> can reproduce the core build with the same end to end hash.

While the scheme you propose does allow verification of rebuildability,
it does not satisfy the requirements for a reproducible build as
understood by the general reproducible builds community:

	When is a build reproducible?

	A build is reproducible if given the same source code, build environment
	and build instructions, any party can recreate bit-by-bit identical
	copies of all specified artifacts.

	The relevant attributes of the build environment, the build instructions
	and the source code as well as the expected reproducible artifacts are
	defined by the authors or distributors. The artifacts of a build are the
	parts of the build results that are the desired primary output.

https://reproducible-builds.org/docs/definition/

Specifically the output of a previous build (the public key, module
signatures) is not available during the rebuild or verification.

> However, is there also a corresponding question of how we verify
> reproduceability of kernel builds (and the associated modules ... I
> assume for the modules you do strip the appended signature)?

Currently distros either don't enforce the reproducibility of the
kernel package at all or disable MODULE_SIG.
With the proposed scheme there would be no signatures on builtin modules.

> I assume
> you're going by the secure boot hash (authenticode hash of the efi stub
> and the compressed payload which includes the key).  However, if we had
> the vmlinux.o we could do a much more nuanced hash to verify the build,
> say by placing the keyring data in a section that isn't hashed.

The currently existing tooling does not have any nuance in its
verifications. It just compares bit-by-bit.
I think this is intentional as any bespoke per-package logic would
introduce possible failure modes and stand in the way of implementing
multiple completely independent verification toolsets.
While bespoke tools like diffoscope exist, these are only for
development and debugging. Not not for the reproducibiliy check itself.

How to handle secure-boot with distro keys is not yet clearly defined.
I see two possibilities, which should be possible with the proposed
scheme, both starting with the build of an unsigned kernel package.
Then a signature would be computed on private infrastructure and either
* shipped in a standalone package, to be combined with the kernel when
  that is installed to the ESP/flash etc.
* used as input of a signed kernel package where it is combined with the
  unsigned kernel image.


Thomas

Powered by blists - more mailing lists