Fwd: Looking for feedback on CONFIG_MODULE_HASHES for Linux
Hi everyone, As discussed during this year's Arch summit, Thomas is seeking help / support from projects that could benefit from his patch set which aims to enable reproducible kernel packages for Linux distributions (see the forwarded mail below). As far as I can tell, this is something we would be interested in. I think it would be nice if we could "officially" claim our interest as "Arch Linux" to hopefully provide some assistance to Thomas for his incoming discussion with upstream. Does any of the kernel packages maintainers on our side wants to jump in (or anyone else interested with some kernel knowledge, I guess)? -------- Forwarded Message -------- Subject: Looking for feedback on CONFIG_MODULE_HASHES for Linux Date: Thu, 13 Nov 2025 21:10:58 +0100 From: Thomas Weißschuh via rb-general <rb-general@lists.reproducible-builds.org> Reply-To: General discussions about reproducible builds <rb-general@lists.reproducible-builds.org> To: rb-general@lists.reproducible-builds.org CC: Thomas Weißschuh <thomas@t-8ch.de> Hi everyone, I am the author of the CONFIG_MODULE_HASHES patchset [0] for the Linux kernel which aims to enable reproducible kernel packages for Linux distributions. My goal is to reignite development and continue with the upstream process. To have a better base to argue with I'd like to get some confirmation that distributions have looked at the patches and do intent to adapt this scheme when it is available in the mainline kernel. That should help me get some leverage with the upstream maintainers. The current form of the patches can be found at [1], they are only slightly adapted from the previous submission to LKML. Remaining open topics before the next submission are proper IMA support and stripping of modules. Future changes may introduce more hash algorithms and performance improvements, but these should not be relvant for now. So if you are packaging Linux for your distribution, have looked at my patches and are eager to use them, please let me know. My plan is to talk with the upstream maintainers at the upcoming Linux Plumbers Conference on 11th of December. Thanks, Thomas [0] https://lore.kernel.org/lkml/20250429-module-hashes-v3-0-00e9258def9e@weisss... [1] https://git.kernel.org/pub/scm/linux/kernel/git/thomas.weissschuh/linux.git/...
On 11/14/25 12:36 PM, Robin Candau wrote:
Hi everyone,
As discussed during this year's Arch summit, Thomas is seeking help / support from projects that could benefit from his patch set which aims to enable reproducible kernel packages for Linux distributions (see the forwarded mail below).
As far as I can tell, this is something we would be interested in. I think it would be nice if we could "officially" claim our interest as "Arch Linux" to hopefully provide some assistance to Thomas for his incoming discussion with upstream.
Does any of the kernel packages maintainers on our side wants to jump in (or anyone else interested with some kernel knowledge, I guess)?
tl;dr: I'm very interested in this patch. There's some prior discussion here (2024): https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/merge_requ... It also has a note from anthraxx from January 2025. :) The only "alternative" approach that has been discussed in Arch Linux throughout the years (that I'm aware of), is "build the `linux` package once with a regular PKGBUILD, generate signatures out of band and add them to source=, edit the PKGBUILD to patch the signing script to use the pre-computed signatures". This needs to be done for every update (both pkgver= but likely also pkgrel=). This would be very involved and if there's a reproducible builds regression this would block further kernel updates or require us to revert the workflow. With the embedded hashing approach we wouldn't need to care about any of this, and there's no special-casing required. Even if there are reproducible builds regressions this wouldn't break/block the regular update process and can be dealt with asynchronously. Important for us would be: - we would have both CONFIG_MODULE_HASHES and CONFIG_MODULE_SIG_KEY set - CONFIG_MODULE_HASHES is used for in-tree modules - CONFIG_MODULE_SIG_KEY is used for out-of-tree modules - module authentication should use `HASH_MATCH || SIGNATURE_MATCH` and not require both (otherwise we wouldn't be able to configure a signing-key for out-of-tree modules without needing to sign our in-tree modules, and we would be back to square one) cheers, kpcyrd
participants (2)
-
kpcyrd
-
Robin Candau