CONFIG_MODULE_SIG and the unreproducible Linux Kernel

[kpcyrd]

On 9/14/24 6:22 PM, James Addison via rb-general wrote:
> 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.

Thanks! Yes, I think this sums it up nicely.

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

Yes, *if* there's an explicit need for additional signed modules and a 
distro-controlled keypair (which Arch Linux currently doesn't have, but 
Debian does for example), then the public key would be configured as a 
stable, well-known build input through something similar to 
CONFIG_MODULE_SIG_KEY. This would be compatible with reproducible builds.

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

Yes that's also correct.

There are additional security advantages of not having a privileged 
keypair (beyond reproducible builds), for the obvious reason that a 
non-existant keypair can't be compromised. Even with an (allegedly) 
ephemerally-generated key there's no way to prove the key wasn't 
retained in some way.

Modules that are part of the kernel package build could be included in 
the embedded hashset (not needing a signature), but a package with 
additional kernel modules would need access to the distro-controlled 
signing key (and therefore not be reproducible).

Hopefully it would be possible to build computers without these 
packages, allowing for systems built with reproducible-only binaries.

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

I'm curious, looking forward to your reply. :)

cheers,
kpcyrd