CONFIG_MODULE_SIG and the unreproducible Linux Kernel

[James Addison]

Hi kpcyrd,

On Sat, 14 Sept 2024 at 15:30, kpcyrd <kpcyrd at archlinux.org> wrote:
>
> Dear list,
>
> there has been a recent public discussion on the Arch Linux gitlab about
> the challenges and possible opportunities for making the Linux kernel
> package reproducible that I want to share:
>
> https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/merge_requests/1
>
> ... [ snip ] ...

Thank you for the interesting read.  Please let me know whether the
summary below seems accurate - and also nitpick anything about it
where relevant:

  * [currently] Linux kernel modules may be signed using public-key
cryptography.

  * [currently] When kernel lockdown mode is enabled, only
acceptably-signed modules can be loaded by the Linux kernel.

  * [currently] Cryptographic signing introduces output randomness --
that is, it is nondeterministic -- and that conflicts with the goal of
bit-for-bit reproducible builds.

  * [proposed] Your suggestion is to replace the lockdown mode's
cryptographic signature verification with integrity hash verification:
to elaborate, kernel modules would be built (reproducibly) with the
cryptographic signature option disabled, and the resulting,
deterministic, integrity hashes of the kernel module (.ko) files would
be embedded into the kernel binary.  The kernel would then refer to
those module integrity hashes to determine whether to load a module or
not.

Two questions / possible misunderstandings:

  * You mention that public-key crypto could still be used to
authenticate other modules -- would that public key be provided as a
stable, constant input to the build process?

  * Relatedly: would the suggestion be anticipated to affect security,
or is it solely focused on achieving build reproducibility?  (what I
am thinking here: if a public key is provided and continues to allow
other modules to be loaded, then that implies that a corresponding
distro-controlled private key exists -- perhaps that key wouldn't be
required during each kernel package build, but it would be required to
sign loadable kernel modules distributed in other packages -- and it
would be as legitimate as any ephemerally-generated build-time private
key).

I have one thought about a limitation that this might introduce, but
I'll try to wait for you to confirm whether I'm following along
correctly first!

Regards,
James