[kernel-bugs] [Bug 1175626] Recent update run on August 21, 2020 kills bootloader
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
http://bugzilla.opensuse.org/show_bug.cgi?id=1175626 http://bugzilla.opensuse.org/show_bug.cgi?id=1175626#c37 --- Comment #37 from John Shaw <johngshaw@twc.com> --- (In reply to Martin Wilck from comment #36)
(In reply to John Shaw from comment #35)
With regard to my reply in comment 34, I do not get to the GRUB menu. If SecureBoot is enabled, failure is an immediate blank screen(s) as the BIOS exits POST. Nothing reboots the machine (eg, cntl-alt-del) other than physically pressing the reboot button.
The question is if the BIOS fails to verify the shim, or shim fails to verify any of the follow-up binaries. Can you check this e.g. with the UEFI shell?
I don't know how to check this in the UEFI shell. Can you explain? However, I managed to get a version of sbverify to work under suse 15.2. How correct this version is is unclear. I got the binary from a ubuntu repo, and I had to jury-rig the libcrypto.1.0.0 library dependency with a symlink to /usr/lib64/libcrypto.so.43. Anyway, it apparently works for the --list option. efi/boot% sudo sbverify --list bootx64.efi warning: data remaining[1172696 vs 1336112]: gaps between PE/COFF sections? signature 1 image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root signature 2 image signature issuers: - /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org image signature certificates: - subject: /CN=openSUSE Secure Boot Signkey/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org issuer: /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org I tested every efi file and the vmlinux images in both /efi/boot and /efi/opensuse, and all BUT /efi/opensuse/grubx64.efi appear to have valid signature certificates. For this I get: % sudo sbverify --list grubx64.efi No signature table present Should grubx86.efi be signed or not? As to using sbverify to actually verify the signatures, I either don't understand what to use for the x509 certificate (for the --cert option), or the utility is broken (as it was not meant for Suse). Its looking for a file here. I tried to save the for keysets in the bios (db, dbx, KEK, PK) and these do seem to be somesort of certificate files, but they don't work in this context. One must be able to get the appropriate (original) certificate from the BIOS, but I don't know how to get it in the correct x509 format.
Other info: In my Asus BIOS, I can effectively disable SecureBoot by selecting "Other OS" vs "Windows UEFI" under the SecureBoot section. This still displays a line stating that SecureBoot is enabled, but the full linux boot sequence works, and mokutil will confirm that it's disabled.
Sounds like broken BIOS.
its the only one I got (well, the most recent one anyway;). Asus does not define this very well. I interpreted "Other OS" as anything that does not use UEFI but clearly my system is not booting from an MBR.
I have read that clearing the BIOS keys also disables SecureBoot, and that the BIOS will state so. I have not tried that method.
I wouldn't recommend that, unless you're certain you can undo it.
Yes, I don't really know what I am doing here. I have the keys backed up, but I can see really screwing this up. I can restore the keys to the orginal factory condition easily as well. I am wondering if its possible that the keys that are in the BIOS are somehow invalid. Still I would expect the BIOS to put put a big red screen and indicate it will not boot. That is difference behavior to hanging the 1st stage boot loader.
Btw the pesign -S output is a pain. No fingerprint or otherwise useful data, just the common name, which could mean anything. And why does it *always* print "Content is detached; signature cannot be verified."?
see my comment above regarding the use of sbverify. Can I use it to try and verify the signitures of the efi files? I just don't know how to supply the correct certificates with it. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com