Fedora Account System
Red Hat Associate
Red Hat Customer
If secure boot is enabled and an attempt is made to boot from an unsigned kernel, grub2 just hangs and does not display a bad shim signature error message. Reproducible: Always Steps to Reproduce: 1. Enable secure boot. 2. Create a custom kernel but do not sign it. 3. Boot from this kernel. Actual Results: Boot hangs without an error message. Expected Results: Bad shim signature error message is displayed. Additional Information: Grub2 version 2.12-42 fails, version 2.12-40 works as expected.
Thanks for the report. I can reproduce this one, and on the serial console I see: Booting `unsigned kernel' !!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - 00000000 !!!! ExceptionData - 0000000000000000 RIP - 00000000792567F4, CS - 0000000000000038, RFLAGS - 0000000000210206 RAX - 000087E000010000, RCX - 000000007BF2BD98, RDX - 000000007BF2BD98 RBX - 0000000000000000, RSP - 000000007BF2BF70, RBP - 000000007BF2BF80 RSI - 00000000000000DD, RDI - 0000000077A7BC40 R8 - 0000000000000000, R9 - 0000000000000020, R10 - 0000000000000000 R11 - 0000000000000000, R12 - 0000000000000000, R13 - 0000000000000000 R14 - 0000000079AA86E8, R15 - 0000000079AA86F0 DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 GS - 0000000000000030, SS - 0000000000000030 CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 000000007BC01000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 000000007B9E1000 0000000000000047, LDTR - 0000000000000000 IDTR - 000000007B157018 0000000000000FFF, TR - 0000000000000000 FXSAVE_STATE - 000000007BF2BBD0 !!!! Find image based on IP(0x792567F4) (No PDB) (ImageBase=000000007923E000, EntryPoint=000000007923F000) !!!! Unfortunately, when I turn on debugging, I do end up seeing the error messages, and can get back to the GRUB menu.
Grub2 from Fedora 44 Beta (version 2.12-55) fails in the same way.
(In reply to David Sandalf from comment #2) > Grub2 from Fedora 44 Beta (version 2.12-55) fails in the same way. Thanks David for testing also in f44. We recently backported a patch fixing an out-of-memory issue and this may be impacting. I am investigating if this is the root cause or some other recent change.
- f44, with latest grub version 2.12-56.fc45 which including the OOM fix, installing a unsigned kernel, rebooting yields to a blank screen and hang. In case the (grub) debug is enabled, it does print the expected error message. If we downgrade grub to pre-OOM fix, grub2-2.12-53.fc44, expected error message is show, no matter debug is enabled or not. - f43, wit latest grub version 2.12-42, a exception type is observed (also reported by Marta). With the same version but debug enabled, expected error message is observed and no expection is observed. if we downgrade grub to pre-OOM fix, in this case grub-2.12-40, expected error is seen in both scenarios, with no debug and with debug enable. In resume, the OOM fix that we recently backported into f44 and f43 are introducing this regressions. Before a possible revert, we need to understand why we are having this dual behavior based on the debug status (enable/disable). This is WIP.
Hi, the newest grub2 versions should fix this for you: grub2-2.12-43.fc43 grub2-2.12-56.fc44 grub2-2.12-57.fc45 Please try updating to the relevant version for your fedora and let us know if it works. thank you! :)
I updated grub2 for F43 to 2.12-43 and it worked (bad shim signature error message for an unsigned kernel, booted a signed one). I will try F44 in when it is released (scheduled for a few days from now).
Bug is fixed in F44.
Team, on affected systems can you please try to boot the latest live ISO from the 'Workstation live' list at https://openqa.fedoraproject.org/nightlies.html and report success or failure? If you have more time, try even installing (on a test/spare/non-production machine) the OS and testing any broken scenario you have in the past due to this problem.
Downloading the iso is slow from the website. You want me to spend over an hour downloading the iso and then boot it just to see if you have reintroduced a bug that was already fixed (see comment 7).
(In reply to David Sandalf from comment #9) > Downloading the iso is slow from the website. You want me to spend over an > hour downloading the iso and then boot it just to see if you have > reintroduced a bug that was already fixed (see comment 7). I want you to test on rawhide, not f44. F44 has no longer that issue because we reverted a OOM (out of memory) fix which regressed on this area. Now we have another OOM fix on rawhide that hopefully will be backported to F44, so this is why I need your help. In other words, testing this scenario (a non-signed shim) under rawhide will give me more confidence to backport it to f44. No idea why download latencies are so high on your end.
I downloaded the live ISO (it went much faster this time) and booted it (using Ventoy). It was successful.
(In reply to David Sandalf from comment #11) > I downloaded the live ISO (it went much faster this time) and booted it > (using Ventoy). It was successful. Thanks David. When you say 'it was successful' you mean the issue is not longer present aka 'Bad shim signature error message is displayed.' ?
I am not sure what you want me to test. What I tested was that a signed kernel (your live ISO kernel) can boot. The bug appears when trying to boot an unsigned kernel.
(In reply to David Sandalf from comment #13) > I am not sure what you want me to test. What I tested was that a signed > kernel (your live ISO kernel) can boot. The bug appears when trying to boot > an unsigned kernel. Have you tried an unsigned kernel? are the bad shim signature msgs shown up? this is the scenario you reported IINM
I am not sure if this is what you want but this is what I did (I don't have a spare machine to test with so I used a VM). 1.I used your ISO to install a system on a VirtualBox VM with Secure Boot enabled. 2.I used pesign to remove the signature from the kernel (vmlinuz file). 3.I rebooted and the bad shim signature appeared as I expected. 4.Just to make sure I turned off Secure Boot in the VM and it booted.
(In reply to David Sandalf from comment #15) > I am not sure if this is what you want but this is what I did (I don't have > a spare machine to test with so I used a VM). > 1.I used your ISO to install a system on a VirtualBox VM with Secure Boot > enabled. > 2.I used pesign to remove the signature from the kernel (vmlinuz file). > 3.I rebooted and the bad shim signature appeared as I expected. > 4.Just to make sure I turned off Secure Boot in the VM and it booted. Thanks David. I believe the above steps are the what you did (or something similar) when reporting the bug so seems like we are good on this and proposed change did fix the problem.