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

["Arnout Engelen" <arnout@bzzt.net>]

On Tue, May 6, 2025, at 15:24, James Bottomley wrote:
> I'll repeat the key point again: all modern hermetic build systems come
> with provenance which is usually a signature.

I'm not sure the 'hermetic build' parallel is so applicable here: typically a
hermetic build will produce an artifact and a signature, and when you embed
that result in a larger aggregate, you only embed the artifact (not the
signature) and sign the aggregate. With module signatures, the module *and*
their signatures are embedded in the aggregate (e.g. ISO, disk image), which is
where (at least in my case) the friction comes from.

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

Right: there is no friction validating the module signatures, that is fine.
There is friction validating the aggregate artifact (e.g. ISO, disk image),
though, because of those signatures embedded into it.

As you mentioned earlier, of course this is *possible* to do (for example by
adding the signatures as inputs to the second 'independent' build or by
creating a hard-to-validate 'check recipe' running the build in reverse).
Still, checking modules at run time by hash instead of by signature would be a
much simpler option for such scenario's.

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

That is interesting history, thanks for digging that up. Of the 2 problems Ben
mentions running into there, '1' does not seem universal (I think this feature
is indeed mainly interesting for systems where you don't _want_ anyone to be
able to load locally-built modules), and '2' is a problem that detached
signatures have but module hashes don't have.

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

I haven't experienced that issue with the module hashes yet.

> 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

Cool, I was aware of that page but didn't know it was initially contributed by
Debian.

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

At least I don't really come to this from the packaging perspective, but from
the "building an independently verifiable ISO/disk image" perspective.
Separating the modules and the signatures into separate packages doesn't help
me there, since they'd still both need to be present on the image.


Kind regards,

-- 
Arnout Engelen
Engelen Open Source
https://engelen.eu