Description of problem: Adding support to automatically sign 3rd part kernel should be easy with the akmods infrastructure. (like with copr kwizart/kernel-longterm-5.15). Steps to Reproduce: 1. dnf install sbsigntools 2. openssl x509 -in public_key.der -inform der -outform pem -out public_key.pem 3. sbsign --key private/private_key.priv --cert certs/public_key.pem /boot/vmlinuz-$(uname -r) --output /boot/vmlinuz-$(uname -r).signed 4 sha512sum /boot/vmlinuz-$(uname -r).signed > /boot/.vmlinuz-$(uname -r).signed.hmac 5. Switch to signed kernel in grub.cfg Actual results: Boots fine with Secure boot kept enabled. Expected results: There is a need to make additional verification Additional info: - Side note is the generated Secure Boot CA key is only valid for 10 years. I don't think we should do this as this will make the signature invalid and users might be unable to boot
One side effect is that kmod signed with the same key than the kernel is unable to load. I need to figure out why ... (do we need to sign kmod and kernel with a different key ?)
See also. https://github.com/vathpela/pesign/blob/wip/src/efikeygen.1.mdoc
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
Hi Nicolas, I'm trying to use the Copr Lts 5.15 kernel In secure mode. All is going well if I don't use Dkms. When I use Dkms for my own modules compiling, without secure mode all is going well also (since months) But When I activate secure mode ,it found wrong signature. All other distributions on same computer are working with same Dkms key pair, so the key is correctly enrolled in Nvram and same Dkms version. I've let a message on Copr site. xuzhen on dkms github seems to found the issue : https://github.com/dell/dkms/issues/305 Can you include the patch for next releases please? Many thanks in advance.
Thanks for finding the issue with this ! I will add the patch to my 5.15 LT copr on the next kernel update. Please remind that 6.1 LT is WIP and should have the patch, as I haven't yet rebase on upstream kernel over fedora tree. I will probably have to sort-out which patches should be kept and other that don't.
Hi, last version 5.15 LTS from yesterday is working, thanks to you.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.