Bug 2020627
| Summary: | Kdump fails on EFI system using secure boot due to dual signature signing | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Frank Büttner <bugzilla> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 37 | CC: | acaringi, adscvr, airlied, alciregi, bhe, bskeggs, coiby.xu, coxu, dustymabe, hdegoede, hpa, jarodwilson, jforbes, josef, kernel-maint, lgoncalv, linville, masami256, mchehab, ptalbert, ruyang, ryncsn, steved |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | kdump:Fedora | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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). |
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: