On the bump to 6.14.y the config entry CONFIG_SND_HDA_SCODEC_TAS2781_SPI was
automatically enabled. This triggered the following compilation bugs:
ERROR: modpost: "crc8" [sound/pci/hda/snd-hda-scodec-tas2781-spi.ko] undefined!
ERROR: modpost: "crc8_populate_msb" [sound/pci/hda/snd-hda-scodec-tas2781-spi.ko] undefined!
In my config, crc8 is disabled and was not enabled again by the mentioned
TAS2781 SPI codec that itself should not have been enabled at all.
As far as I can see I'll definietly need xt_comment, enabled
by config entry CONFIG_NETFILTER_XT_MATCH_COMMENT, but let's
just enable the rest as module, too.
The xt_comment module is used by some projects using docker-compose
(with podman-5.4.1 and podman-compose-1.3.0).
I never ran it on purpose and it looks to me as it was
enabled 'by accident' on an earlier kernel bump in 2021
in commit 20a7ab2a5adaeb42f5cfd25d29d82a1060ac4ccd.
For some reference, see the following commits:
4d8812597bfc661bfa4c54ee08e4ce4da4caacc2 aptenodytes, eudyptes: Switch to zstd
672ae7c496ec5b2ac0ff5563991eb98fcdf5311a pygoscelis: Try out zstd for kernel and initramfs
(052d3b965b369b07339ca15ec273d7111ecd222f pygoscelis: Use zstd for panic logs)
Part 1, enable AES-NI
That this was even disabled is weird.
Part 2, disable the "AMD Secure Processor"
Looks as it's blocking AES-NI and my kernel does not support it:
`modprobe: ERROR: could not insert 'ccp_crypto': No such device`
and
`ccp_crypto: Cannot load: there are no available CCPs`
This disables CONFIG_GENTOO_KERNEL_SELF_PROTECTION_COMMON by itself
and lockdown by choice as my system did not let me hibernate with
enabled lockdown, even though fwupdmgr recognized the encrypted swap.
For the decryption of swap I added a second rd.luks.uuid entry
aswell as resume=UUID=... - first one pointing to the outside LUKS
container, second one to the unlocked swap partition.
For now I have to enter passphrases for / and swap at boot and resume.
Starting with 6.13.6-T14s, my kernel signing key will be placed outside
the kernel build dir and thus not installed into the world-readable location
`/usr/src/linux/certs`.
It's configured by flags for portage in `/etc/portage/make.conf/MODULES_SIGN`:
```
MDOULES_SIGN_CERT=".../signing_cert.pem"
MODULES_SIGN_HASH="sha3-512"
MODULES_SIGN_KEY=".../signing_key.pem"
```
generated using this script:
```
#!/bin/bash
set -uxa pipefail
__VERSION__="2025-03-09"
TODAY="$(date --utc +%Y-%m-%d)"
SIGN_KVER="6.13.y"
MY_PRIV_KEY_FILE="${TODAY}.signing_key.pem"
MY_PUB_CERT_FILE="${TODAY}.signing_cert.pem"
MY_OPENSSL_PARAMS=(
req
-new
-sha512
-newkey rsa:4096
# don't encrypt the file
-noenc
# validity: 1024 years, given in days
-days 374016
-x509
-keyout "${MY_PRIV_KEY_FILE}"
-out "${MY_PUB_CERT_FILE}"
# adopt to usage
# keep umlauts in mind, the seem to break here...
-subj "/C=DE/ST=Baden-Wuerttemberg/L=Karlsruhe/O=/OU=/CN=kernel module signing key (${TODAY}, ${SIGN_KVER})/"
)
openssl "${MY_OPENSSL_PARAMS[@]}"
openssl x509 -noout -text -in "${MY_PUB_CERT_FILE}"
```
This change brings the benefit that I can use binpkgs on my machine, do
not need to delete my keys from world-readable `/usr/src/linux` anymore
and can even think about distributing my kernel binary packages.
One negative change is that I'll have to remember to roll-over the keys
myself from time to time.
