Comment # 37 on bug 1175626 from John Shaw

(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.