Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking

[Nicolas Schier <nsc@kernel.org>]

On Mon, Feb 23, 2026 at 10:43:30PM +0100, Thomas Weißschuh wrote:
> On 2026-02-23 19:41:52+0100, Nicolas Schier wrote:
> > On Mon, Feb 23, 2026 at 08:53:29AM +0100, Thomas Weißschuh wrote:
> > > On 2026-02-21 22:38:29+0100, Nicolas Schier wrote:
> > > > On Tue, Jan 13, 2026 at 01:28:59PM +0100, Thomas Weißschuh wrote:
[...]
> > > > [...]
> > > > > diff --git a/scripts/modules-merkle-tree.c b/scripts/modules-merkle-tree.c
> > > > > new file mode 100644
> > > > > index 000000000000..a6ec0e21213b
> > > > > --- /dev/null
> > > > > +++ b/scripts/modules-merkle-tree.c
> > > > > @@ -0,0 +1,467 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > > +/*
> > > > > + * Compute hashes for modules files and build a merkle tree.
> > > > > + *
> > > > > + * Copyright (C) 2025 Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> > > > > + * Copyright (C) 2025 Thomas Weißschuh <linux@weissschuh.net>
> > > > > + *
> > > > > + */
> > > > > +#define _GNU_SOURCE 1
> > > > > +#include <arpa/inet.h>
> > > > > +#include <err.h>
> > > > > +#include <unistd.h>
> > > > > +#include <fcntl.h>
> > > > > +#include <stdarg.h>
> > > > > +#include <stdio.h>
> > > > > +#include <string.h>
> > > > > +#include <stdbool.h>
> > > > > +#include <stdlib.h>
> > > > > +
> > > > > +#include <sys/stat.h>
> > > > > +#include <sys/mman.h>
> > > > > +
> > > > > +#include <openssl/evp.h>
> > > > > +#include <openssl/err.h>
> > > > > +
> > > > > +#include "ssl-common.h"
> > > > > +
> > > > > +static int hash_size;
> > > > > +static EVP_MD_CTX *ctx;
> > > > > +
> > > > > +struct module_signature {
> > > > > +	uint8_t		algo;		/* Public-key crypto algorithm [0] */
> > > > > +	uint8_t		hash;		/* Digest algorithm [0] */
> > > > > +	uint8_t		id_type;	/* Key identifier type [PKEY_ID_PKCS7] */
> > > > > +	uint8_t		signer_len;	/* Length of signer's name [0] */
> > > > > +	uint8_t		key_id_len;	/* Length of key identifier [0] */
> > > > > +	uint8_t		__pad[3];
> > > > > +	uint32_t	sig_len;	/* Length of signature data */
> > > > > +};
> > > > > +
> > > > > +#define PKEY_ID_MERKLE 3
> > > > > +
> > > > > +static const char magic_number[] = "~Module signature appended~\n";
> > > > 
> > > > This here will be the forth definition of struct module_signature,
> > > > increasing the risk of unwanted diversion.  I second Petr's suggestion
> > > > to reuse a _common_ definition instead.
> > > 
> > > Ack.
> > > 
> > > > (Here, even include/linux/module_signature.h could be included itself.)
> > > 
> > > I'd like to avoid including internal headers from other components.
> > > We could move it to an UAPI header. Various other subsystems use those
> > > for not-really-UAPI but still ABI definitions.
> > 
> > Yeah, ack.
> 
> What exactly is the 'ack' for?
> * Avoiding to include internal headers?
> * Moving the definition to UAPI headers?

ah, sorry.  I think reduction of duplicated definitions is good; moving
these definitions to UAPI headers sounds like a valid compromise to me.


> (...)
> 
> > > > Can you verify if I get the mechanics roughly correct?
> > > > 
> > > >   * Modules are merkle tree leaves.  Modules are built and logically
> > > >     paired by the order from modules.order; a single left-over module is
> > > >     paired with itself.
> > > > 
> > > >   * Hashes of paired modules are hashed again (branch node hash);
> > > >     hashes of pairs of branch nodes' hashes are hashed again;
> > > >     repeat until we reach the single merkle tree root hash
> > > > 
> > > >   * The final merkle tree root hash (and the count of tree levels) is
> > > >     included in vmlinux
> > > 
> > > The merkle tree code was written by Sebastian so he will have the best
> > > knowledge about it. But this is also my understanding.
> > 
> > I'd like to see some (rough) description in Documentation or in a commit
> > message at least, otherwise future me will have to ask that again.
> 
> Ack in general. I'd prefer to document it in a source code comment,
> though. That feels like the best fit to me.

Great, thanks.

-- 
Nicolas