The vanilla sources fill the directory /usr/src/linux/certs/ with the required data. It is possible to automatically create a signing_key.pem. It is also possible (like here) to create my own certificate with a x509.genkey I wrote. tux# /usr/src/linux-5.14.7-vanilla/certs # ls Kconfig blacklist.c blacklist.o blacklist_nohashes.c built-in.a common.h modules.order signing_key.pem system_certificat> Makefile blacklist.h blacklist_hashes.c blacklist_nohashes.o common.c common.o revocation_certificates.S signing_key.x509 system_certificat> The xxx-kernel (-dist) supplied by gentoo have only 2 files in the cert directory. So it is impossible to sign the kernel modules. This breaks the security chain during secure-boot. tux# /usr/src/linux-5.14.7-gentoo-dist-hardened/certs # ls Kconfig Makefile A file in /etc/kernel/config.d/module-auto-signature.config with the content: # cat module-auto-signatur.config CONFIG_MODULE_SIG=y CONFIG_MODULE_SIG_FORCE=y CONFIG_MODULE_SIG_ALL=y CONFIG_MODULE_SIG_SHA512=y CONFIG_MODULE_SIG_HASH="sha512" CONFIG_MODULE_SIG_KEY="certs/signing_key.pem" is ineffective and results in rotating random errors and unbootable kernels. All gentoo -dist versions are affected. The gentoo-sources are ok ls /usr/src/linux-5.14.7-gentoo/certs/ Kconfig blacklist.c blacklist_hashes.c common.c revocation_certificates.S system_keyring.c Makefile blacklist.h blacklist_nohashes.c common.h system_certificates.S
Correction The command "make modules_install" should be sufficient to install and sign the modules. Like this: tux /usr/src/linux-5.14.7-vanilla # make modules_install INSTALL /lib/modules/5.14.7-vanilla-hard/kernel/arch/x86/crypto/aegis128-aesni.ko SIGN /lib/modules/5.14.7-vanilla-hard/kernel/arch/x86/crypto/aegis128-aesni.ko INSTALL /lib/modules/5.14.7-vanilla-hard/kernel/arch/x86/crypto/blake2s-x86_64.ko SIGN /lib/modules/5.14.7-vanilla-hard/kernel/arch/x86/crypto/blake2s-x86_64.ko INSTALL /lib/modules/5.14.7-vanilla-hard/kernel/arch/x86/crypto/blowfish-x86_64.ko SIGN /lib/modules/5.14.7-vanilla-hard/kernel/arch/x86/crypto/blowfish-x86_64.ko INSTALL /lib/modules/5.14.7-vanilla-hard/kernel/arch/x86/crypto/camellia-aesni-avx-x86_64.ko SIGN /lib/modules/5.14.7-vanilla-hard/kernel/arch/x86/crypto/camellia-aesni-avx-x86_64.ko In the gentoo-sources the signature is not done: tux /usr/src/linux-5.10.68-gentoo # make modules_install INSTALL arch/x86/crypto/aegis128-aesni.ko INSTALL arch/x86/crypto/blake2s-x86_64.ko INSTALL arch/x86/crypto/blowfish-x86_64.ko INSTALL arch/x86/crypto/camellia-aesni-avx-x86_64.ko INSTALL arch/x86/crypto/camellia-aesni-avx2.ko At boot time, the unsigned modules are rejected by the kernel. The boot process crashes. This means that all gentoo kernels/sources are affected by this error. A full secure boot is currently not possible with gentoo.
(In reply to Tuxine from comment #1) > A full secure boot is currently not possible with gentoo. It is, people do it. This doesn't actually appear to be vulnerability but an issue with the dist-kernels, so reassigning.
the autogenerated key is not installed by dist-kernel, this is an upstream choice I'm pretty sure. This means you'll have to do some manual intervention: With dist-kernel you have multiple options for getting signed modules to work. First off, if you're using an initramfs make sure it doesn't strip the modules - for dracut, this can be done with do_strip="false" in /etc/dracut.conf.d First option: sign the modules after installation with your secureboot key - this requires CONFIG_INTEGRITY_PLATFORM_KEYRING=y Second option: have a certificate on your filesystem, and point at it via CONFIG_MODULE_SIG_KEY. This cert can also be password protected (this is needed because portage builds as non-root, and thus the cert needs to be readable) and Kbuild will unlock it with the password given with the KBUILD_SIGN_PIN environment variable. Both options REQUIRE you to sign the certs manually after installation, since modules get stripped during installation and this'd strip the signature. For this I'm using a script placed in /etc/kernel/postinst.d: find /lib/modules/"${VER}" -regex '.*\.ko$' -type f -exec "${SIGNCMD}" sha512 ${KEYFILE} ${KEYFILE} {} \; with the following variables: VER="${1}" SIGNCMD="/usr/src/linux-${VER}/scripts/sign-file" and KEYFILE being the path of my certificate. This is for uncompressed modules, change the .ko file ending appropriately for your compression type. As for why gentoo-sources doesn't sign, no idea
(In reply to Jannik Glückert from comment #3) I have now used sys-kernel/gentoo-sources-5.14.8. I have not made any changes to my configurations. It works fine. Linux tux 5.14.8-gentoo #1 SMP Tue Sep 28 08:23:35 CEST 2021 x86_64 AMD Ryzen 5 3600 6-Core Processor AuthenticAMD GNU/Linux Linux tux 5.14.8-gentoo-91-kspp #1 SMP Tue Sep 28 08:23:35 CEST 2021 x86_64 AMD Ryzen 5 3600 6-Core Processor AuthenticAMD GNU/Linux Secure boot enabled Loaded X.509 cert 'Gentoo-Module-Signing-Key: 83a41664cf58592ead94a68f984c1583e0b84f82' The proposed solution 2. for the -dist kernel is too difficult for me. Thank you for your time solved
(In reply to Jannik Glückert from comment #3) > the autogenerated key is not installed by dist-kernel, this is an upstream > choice I'm pretty sure. This means you'll have to do some manual > intervention: This was fixed some time ago by the introduction of USE=modules-sign
