Description of problem: On an system using EFI and secure boot, kudmp can't be started. Version-Release number of selected component (if applicable): kexec-tools-2.0.22-4.fc34.x86_64 How reproducible: Every time Steps to Reproduce: 1. start the system 2. control the status of the kdump service Actual results: sudo systemctl status kdump × kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2021-11-05 13:41:01 CET; 1min 3s ago Process: 2184 ExecStart=/usr/bin/kdumpctl start (code=exited, status=1/FAILURE) Main PID: 2184 (code=exited, status=1/FAILURE) CPU: 1.022s Nov 05 13:41:00 foo systemd[1]: Starting Crash recovery kernel arming... Nov 05 13:41:01 foo kdumpctl[2190]: kdump: Secure Boot is enabled. Using kexec file based syscall. Nov 05 13:41:01 foo kdumpctl[2190]: kdump: kexec: failed to load kdump kernel Nov 05 13:41:01 foo kdumpctl[2190]: kdump: Starting kdump: [FAILED] Nov 05 13:41:01 foo systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE Nov 05 13:41:01 foo systemd[1]: kdump.service: Failed with result 'exit-code'. Nov 05 13:41:01 foo systemd[1]: Failed to start Crash recovery kernel arming. Nov 05 13:41:01 foo systemd[1]: kdump.service: Consumed 1.022s CPU time. Expected results: Working kumpd Additional info:
Hi Frank, Thanks for reporting this issue. Can you paste the output of the following command? $ pesign -S --in /boot/vmlinuz-`uname -r`
Hi Coiby, here the output as requested: pesign -S --in /boot/vmlinuz-`uname -r` --------------------------------------------- certificate address is 0x7f6aeb88e948 Content was not encrypted. Content is detached; signature cannot be verified. The signer's common name is Fedora Secure Boot Signer No signer email address. Signing time: Wed Oct 27, 2021 There were certs or crls included. --------------------------------------------- certificate address is 0x7f6aeb88f290 Content was not encrypted. Content is detached; signature cannot be verified. The signer's common name is kernel-signer No signer email address. Signing time: Wed Oct 27, 2021 There were certs or crls included. ---------------------------------------------
Hi Frank, This is a known issue. Currently kernel can't verify kernel image that has multiple signatures. A workaround is to remove the 2nd signature, cp /boot/vmlinuz-`uname -r`{,.bak} pesign --signature-number=1 -f -r -i /boot/vmlinuz-`uname -r`.bak -o /boot/vmlinuz-`uname -r`
Hi Justin, Is there a plan for Fedora to only sign kernel image once? Thanks!
(In reply to Coiby from comment #4) > Hi Justin, > > Is there a plan for Fedora to only sign kernel image once? Thanks! Eventually, but it is going to be a while.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. 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 '34'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 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 message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. 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 '35'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 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.
Same for F36, but I can't set the version to 36.
(In reply to Frank Büttner from comment #8) > Same for F36, but I can't set the version to 36. I was able to update it.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. 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 '36'. 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 36 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.
It should be a kernel issue, so let's move the component to kernel
(In reply to Justin M. Forbes from comment #5) > (In reply to Coiby from comment #4) > > Hi Justin, > > > > Is there a plan for Fedora to only sign kernel image once? Thanks! > > Eventually, but it is going to be a while. The certificate used for verify the kexec'ed kernel image has expired, $ pesign -i /boot/vmlinuz-`uname -r` --export-signature 1.sig -u 0 $ openssl pkcs7 -inform DER -print_certs -in 1.sig -out 1.pem $ openssl x509 -text -in 1.pem Certificate: Data: Signature Algorithm: sha256WithRSAEncryption Issuer: CN = Fedora Secure Boot CA Validity Not Before: Dec 7 16:04:24 2012 GMT Not After : Dec 5 16:04:24 2022 GMT I think it's time to remove the expired signature. Otherwise secureboot won't work for kexec (the workaround in comment#3 is also invalid now).
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.
Hi Justin, Any new plan about this? Who would be the right person to help on this bz?
To avoid being closed automatically I reset the version to 38, if it is not a bug in F38, please feel free to reset.
From what I know, we have to have a new shim build signed before we can drop the dual signatures. This has been held up for a while. There has been a blocker bug for the last few releases which also requires a new shim, and keeps getting deferred. I believe I last spoke to Peter about this the week before F39 shipped and we have a path forward now, but it will likely still take a month or 2.
Justin, thanks for the update
shim-15.8-2 has been released to resolve bz2198977. So now shim has switched to the new cert and I think it's time to drop the old kernel signature, [root@hpe-dl20gen9-01 ~]# rpm -q shim-x64 shim-x64-15.8-2.x86_64 [root@hpe-dl20gen9-01 ~]# mokutil --list-enrolled [key 1] SHA1 Fingerprint: 2b:b0:10:e2:4d:94:c6:32:24:58:89:ba:aa:9e:d0:f3:d5:ef:1f:68 Certificate: Data: Version: 3 (0x2) Serial Number: 22:39:af:04:13:0c:44:44:b3:f3:77:ed:be:1a:f7:86 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca Validity Not Before: Jul 13 17:31:16 2020 GMT Not After : Jan 19 03:14:07 2037 GMT
I can confirm on rawhide with `shim-x64-15.8-3.x86_64` our CoreOS ext.config.kdump.crash tests passes with secureboot enabled. `-2` didn't work at all for us (see https://bugzilla.redhat.com/show_bug.cgi?id=2270355) but that's fixed with `-3`.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. 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 '38'. 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 38 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.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
The rawhide kernel has the signature signed by the expired certificate removed but F40 and F39 still have the problem.
The expired signature has been removed: $ pesign -S -i /boot/vmlinuz-6.9.4-200.fc40.x86_64 --------------------------------------------- certificate address is 0x7f3580527208 Content was not encrypted. Content is detached; signature cannot be verified. The signer's common name is kernel-signer No signer email address. Signing time: Wed Jun 12, 2024 There were certs or crls included. ---------------------------------------------
(In reply to Steve from comment #23) > The expired signature has been removed: > > $ pesign -S -i /boot/vmlinuz-6.9.4-200.fc40.x86_64 > --------------------------------------------- > certificate address is 0x7f3580527208 > Content was not encrypted. > Content is detached; signature cannot be verified. > The signer's common name is kernel-signer > No signer email address. > Signing time: Wed Jun 12, 2024 > There were certs or crls included. > --------------------------------------------- Thanks for the info! I can confirm kdump.service can be started successfully when UEFI secure boot is enabled.