public inbox for linux-modules@vger.kernel.org
 help / color / mirror / Atom feed
From: "Mihai-Drosi Câju" <mcaju95@gmail.com>
To: linux@weissschuh.net
Cc: arnd@arndb.de, arnout@bzzt.net, atomlin@atomlin.com,
	bigeasy@linutronix.de, chleroy@kernel.org, christian@heusel.eu,
	corbet@lwn.net, coxu@redhat.com, da.gomez@kernel.org,
	da.gomez@samsung.com, dmitry.kasatkin@gmail.com,
	eric.snowberg@oracle.com, f.gruenbichler@proxmox.com,
	jmorris@namei.org, kpcyrd@archlinux.org,
	linux-arch@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-integrity@vger.kernel.org, linux-kbuild@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, lkp@intel.com,
	maddy@linux.ibm.com, mattia@mapreri.org, mcaju95@gmail.com,
	mcgrof@kernel.org, mpe@ellerman.id.au, nathan@kernel.org,
	naveen@kernel.org, nicolas.bouchinet@oss.cyber.gouv.fr,
	nicolas.schier@linux.dev, npiggin@gmail.com, nsc@kernel.org,
	paul@paul-moore.com, petr.pavlu@suse.com,
	roberto.sassu@huawei.com, samitolvanen@google.com,
	serge@hallyn.com, xiujianfeng@huawei.com, zohar@linux.ibm.com
Subject: Re: [PATCH v4 00/17] module: Introduce hash-based integrity checking
Date: Sat, 31 Jan 2026 09:36:36 +0200	[thread overview]
Message-ID: <20260131073636.65494-1-mcaju95@gmail.com> (raw)
In-Reply-To: <20260113-module-hashes-v4-0-0b932db9b56b@weissschuh.net>

> 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.

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).

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.

So a traditional workflow would be:
compiled_module + module_signature == module

In this case we build the module, sign it with whatever key, distribute the
builds and the private key to whoever wants to reproduce the build. Or we build
locally and the key stays with the end-user.

While the cryptographic approach would be:
verify(compiled_code, module.signature) is True

In this case we distribute the builds, source code and the public key. While
everyone can ensure that the compiled code is the result of the build
environment and source code. The signature is verified using cryptographic
means.

As long as no one cracks RSA or an algorithm of our choosing/has an absurd
amount of luck, the cryptographic approach would be just as good as the traditional
approach at ensuring that a program has stopped with a certain output.

  parent reply	other threads:[~2026-01-31  7:36 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-13 12:28 [PATCH v4 00/17] module: Introduce hash-based integrity checking Thomas Weißschuh
2026-01-13 12:28 ` [PATCH v4 01/17] module: Only declare set_module_sig_enforced when CONFIG_MODULE_SIG=y Thomas Weißschuh
2026-01-13 12:28 ` [PATCH v4 02/17] powerpc/ima: Drop unnecessary check for CONFIG_MODULE_SIG Thomas Weißschuh
2026-01-30 20:43   ` Aaron Tomlin
2026-02-06  8:25   ` Nicolas Schier
2026-03-10 21:11   ` Eric Biggers
2026-01-13 12:28 ` [PATCH v4 03/17] ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG Thomas Weißschuh
2026-01-30 20:49   ` Aaron Tomlin
2026-02-06  8:25   ` Nicolas Schier
2026-03-10 21:11   ` Eric Biggers
2026-01-13 12:28 ` [PATCH v4 04/17] module: Make mod_verify_sig() static Thomas Weißschuh
2026-01-30 20:53   ` Aaron Tomlin
2026-02-06  8:25   ` Nicolas Schier
2026-03-10 21:12   ` Eric Biggers
2026-01-13 12:28 ` [PATCH v4 05/17] module: Switch load_info::len to size_t Thomas Weißschuh
2026-02-06  8:18   ` David Howells
2026-02-06  8:34     ` Thomas Weißschuh
2026-02-06  8:30   ` Nicolas Schier
2026-02-06  8:38     ` Thomas Weißschuh
2026-02-06  8:55       ` Nicolas Schier
2026-02-06  9:09   ` Christophe Leroy (CS GROUP)
2026-02-06  9:18     ` Thomas Weißschuh
2026-01-13 12:28 ` [PATCH v4 06/17] kbuild: add stamp file for vmlinux BTF data Thomas Weißschuh
2026-02-06 16:28   ` Nicolas Schier
2026-03-10 21:36   ` Eric Biggers
2026-03-11 12:58     ` Thomas Weißschuh
2026-01-13 12:28 ` [PATCH v4 07/17] kbuild: generate module BTF based on vmlinux.unstripped Thomas Weißschuh
2026-02-06 16:37   ` Nicolas Schier
2026-01-13 12:28 ` [PATCH v4 08/17] module: Deduplicate signature extraction Thomas Weißschuh
2026-01-27 15:20   ` Petr Pavlu
2026-02-03 12:41     ` Thomas Weißschuh
2026-01-13 12:28 ` [PATCH v4 09/17] module: Make module loading policy usable without MODULE_SIG Thomas Weißschuh
2026-03-10 22:01   ` Eric Biggers
2026-03-11 12:59     ` Thomas Weißschuh
2026-01-13 12:28 ` [PATCH v4 10/17] module: Move integrity checks into dedicated function Thomas Weißschuh
2026-02-13 15:09   ` Nicolas Schier
2026-03-10 22:06   ` Eric Biggers
2026-01-13 12:28 ` [PATCH v4 11/17] module: Move lockdown check into generic module loader Thomas Weißschuh
2026-02-13 15:14   ` Nicolas Schier
2026-01-13 12:28 ` [PATCH v4 12/17] module: Move signature splitting up Thomas Weißschuh
2026-01-29 14:41   ` Petr Pavlu
2026-02-03 12:42     ` Thomas Weißschuh
2026-01-13 12:28 ` [PATCH v4 13/17] module: Report signature type to users Thomas Weißschuh
2026-01-29 14:44   ` Petr Pavlu
2026-02-03 12:44     ` Thomas Weißschuh
2026-01-13 12:28 ` [PATCH v4 14/17] lockdown: Make the relationship to MODULE_SIG a dependency Thomas Weißschuh
2026-02-13 15:32   ` Nicolas Schier
2026-01-13 12:28 ` [PATCH v4 15/17] module: Introduce hash-based integrity checking Thomas Weißschuh
2026-01-13 14:56   ` Sebastian Andrzej Siewior
2026-01-30 17:06   ` Petr Pavlu
2026-02-03 12:55     ` Thomas Weißschuh
2026-02-06 17:12       ` Nicolas Schier
2026-02-19 14:27       ` Nicolas Schier
2026-02-03 12:19   ` Petr Pavlu
2026-02-03 12:59     ` Thomas Weißschuh
2026-03-11  1:18     ` Eric Biggers
2026-02-21 21:38   ` Nicolas Schier
2026-02-23  7:53     ` Thomas Weißschuh
2026-02-23 18:41       ` Nicolas Schier
2026-02-23 21:43         ` Thomas Weißschuh
2026-02-24 16:14           ` Nicolas Schier
2026-03-11  1:12   ` Eric Biggers
2026-03-11  8:50     ` Sebastian Andrzej Siewior
2026-03-11 13:19     ` Thomas Weißschuh
2026-03-11 21:14       ` Eric Biggers
2026-01-13 12:29 ` [PATCH v4 16/17] kbuild: move handling of module stripping to Makefile.lib Thomas Weißschuh
2026-01-13 12:29 ` [PATCH v4 17/17] kbuild: make CONFIG_MODULE_HASHES compatible with module stripping Thomas Weißschuh
2026-01-31  7:36 ` Mihai-Drosi Câju [this message]
2026-02-01 16:22   ` [PATCH v4 00/17] module: Introduce hash-based integrity checking Thomas Weißschuh
2026-02-01 17:09   ` David Howells
2026-02-01 20:12     ` Eric Biggers
2026-02-02  9:21       ` David Howells
2026-02-02 18:30         ` Eric Biggers
2026-02-02 18:38           ` David Howells
2026-02-02 18:47             ` Eric Biggers
2026-02-03  8:18     ` James Bottomley
2026-02-03  8:22       ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260131073636.65494-1-mcaju95@gmail.com \
    --to=mcaju95@gmail.com \
    --cc=arnd@arndb.de \
    --cc=arnout@bzzt.net \
    --cc=atomlin@atomlin.com \
    --cc=bigeasy@linutronix.de \
    --cc=chleroy@kernel.org \
    --cc=christian@heusel.eu \
    --cc=corbet@lwn.net \
    --cc=coxu@redhat.com \
    --cc=da.gomez@kernel.org \
    --cc=da.gomez@samsung.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=eric.snowberg@oracle.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=jmorris@namei.org \
    --cc=kpcyrd@archlinux.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lkp@intel.com \
    --cc=maddy@linux.ibm.com \
    --cc=mattia@mapreri.org \
    --cc=mcgrof@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=nathan@kernel.org \
    --cc=naveen@kernel.org \
    --cc=nicolas.bouchinet@oss.cyber.gouv.fr \
    --cc=nicolas.schier@linux.dev \
    --cc=npiggin@gmail.com \
    --cc=nsc@kernel.org \
    --cc=paul@paul-moore.com \
    --cc=petr.pavlu@suse.com \
    --cc=roberto.sassu@huawei.com \
    --cc=samitolvanen@google.com \
    --cc=serge@hallyn.com \
    --cc=xiujianfeng@huawei.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox