Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sat, 2025-05-03 at 10:19 +0200, Arnout Engelen wrote:
> On Fri, May 2, 2025, at 15:30, James Bottomley wrote:
> > On Fri, 2025-05-02 at 08:53 +0200, Thomas Weißschuh wrote:
> > > Specifically the output of any party can recreate bit-by-bit
> > > identical copies of all specified artifacta previous build (the
> > > public key, module signatures) is not available during the
> > > rebuild or verification.
> > 
> > You just strip the signatures before verifying reproducibility.
> 
> If the goal is: "verify the Linux Kernel is reproducible", that could
> work. It gets increasingly cumbersome when you're trying to check the
> reproducibility of some larger artifact that embeds the Linux kernel
> (and lots of other stuff), like an ISO or disk image, though: you'd
> have to unpack/mount it, check all its contents individually (perhaps
> recursively), and strip signatures in 'just the right places'.

Most GPL/LGPL software requires a build recipe anyway.  Realistically,
you're just proving you can exercise that in reverse.

> Writing such tooling is a chore, but of course feasible: diffoscope
> already comes a long way (though checking large images may take some
> resources). The problem is trusting such tooling: instead of 'simply'
> checking the images are identical, suddenly I now have to convince
> myself there's no shenanigans possible in the disk image
> interpretation and other check tooling, which gets nontrivial fast.

I'll repeat the key point again: all modern hermetic build systems come
with provenance which is usually a signature.  Developing the tooling
is already a requirement.

Plus, you've got to remember that a signature is a cryptographic
function of the hash over the build minus the signature.  You can't
verify a signature unless you know how to get the build minus the
signature.  So the process is required to be deterministic.

> > All current secure build processes (hermetic builds, SLSA and the
> > like) are requiring output provenance (i.e. signed artifacts).  If
> > you try to stand like Canute against this tide saying "no signed
> > builds", you're simply opposing progress for the sake of it
> 
> I don't think anyone is saying 'no signed builds', but we'd enjoy
> being able to keep the signatures as detached metadata instead of
> having to embed them into the 'actual' artifacts.

We had this debate about 15 years ago when Debian first started
reproducible builds for the kernel.  Their initial approach was
detached module signatures.  This was the original patch set:

https://lore.kernel.org/linux-modules/20160405001611.GJ21187@decadent.org.uk/

And this is the reason why Debian abandoned it:

https://lists.debian.org/debian-kernel/2016/05/msg00384.html

The specific problem is why detached signatures are almost always a
problem: after a period of time, particularly if the process for
creating updated artifacts gets repeated often matching the output to
the right signature becomes increasingly error prone.

Debian was, however, kind enough to attach what they currently do to
get reproducible builds to the kernel documentation:

https://docs.kernel.org/kbuild/reproducible-builds.html

Although they went for deterministic signing, I will note that it is
perfectly possible to follow their receipe with an ephemeral
certificate as well.

However, if you want to detach the module signatures for packaging, so
the modules can go in a reproducible section and the signatures
elsewhere, then I think we could accommodate that (the output of the
build is actually unsigned modules, they just get signed on install).

Regards,

James