Installing Leap 16.0 with secure boot disabled

English Install/Boot/Login
1

I use a multiboot USB with several Linux distributions to boot. It is done essentially by installing Grub in the USB, copying distribution ISOs, and creating a suiting grub.cfg.

Only problem is, even after many tries and internet searches, this USB doesn’t work with secure boot enabled, so I always have to disable it (though retaining UEFI mode) to boot the USB.

I want to install Leap 16.0 from this USB. I already saw that installer is very different from the Leap 15 series. In Leap 15 series there was an option in the Software section for enabling/disabling secure boot support, so no matter if I had secure boot disabled, it was very well supported once secure boot was enabled back.

Is this the same case in Leap 16.0 installer?
If not, how can I solve it if I need to previously disable secure boot in bios? I want Leap 16.0 to work with secure boot enabled.

Thanks for your help.

1 Like
2

Hello!

As all binaries in “Chain of Trust” are signed - you have to ensure that these signatures match.

First you should see, what keys are allowed in your SecureBoot configuration with:

$ mokutil -l -a --short
MokListRT]                                                                                                                       
bca4e38ed1 SUSE Linux Enterprise Secure Boot CA                                                                                   
[MokListXRT]                                                                                                                      
0000000000 (sha256)                                                                                                               
[PK]                                                                                                                              
cdcf075ae4 Debian UEFI Secure Boot (PK/KEK key)                                                                                   
[KEK]                                                                                                                             
cdcf075ae4 Debian UEFI Secure Boot (PK/KEK key)                                                                                   
31590bfd89 Microsoft Corporation KEK CA 2011                                                                                      
459ab6fb5e Microsoft Corporation KEK 2K CA 2023                                                                                   
[db]                                                                                                                              
580a6f4cc4 Microsoft Windows Production PCA 2011                                                                                  
45a0fa3260 Windows UEFI CA 2023                                                                                                   
46def63b5c Microsoft Corporation UEFI CA 2011                                                                                     
b5eeb4a670 Microsoft UEFI CA 2023                                                                                                 
[dbx]                                                                                                                             
80b4d96931 (sha256)

Next you need to verify what binaries are loaded and what signatures they have:

$ efibootmgr 

BootCurrent: 0004
Timeout: 3 seconds
...
Boot0004* openSUSE Boot Manager (systemd-boot)  HD(1,GPT,538062a0-75c2-4f05-b81f-c4775f4712a6,0x800,0x100000)/File(\EFI\systemd\shim.efi)

So in my case I have to look, who signed shim.efi with:

$ sbverify --list /boot/efi/EFI/systemd/shim.efi                                                        

warning: data remaining[914208 vs 1042192]: 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:                                                                                                          
 - /C=US/O=Microsoft Corporation/CN=Microsoft UEFI CA 2023                                                                        
image signature certificates:                                                                                                     
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft UEFI CA 2023 signer                                
   issuer:  /C=US/O=Microsoft Corporation/CN=Microsoft UEFI CA 2023                                                               
 - subject: /C=US/O=Microsoft Corporation/CN=Microsoft UEFI CA 2023                                                               
   issuer:  /C=US/O=Microsoft Corporation/CN=Microsoft RSA Devices Root CA 2021                                                   
signature 3                                                                                                                       
image signature issuers:                                                                                                          
 - /CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build@suse.de  
image signature certificates:                                                                                                     
 - subject: /CN=SUSE Linux Enterprise Secure Boot Signkey/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=b
uild@suse.de                                                                                                                      
   issuer:  /CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build$
suse.de

The chain continues with grub.efi:

$ sbverify --list /boot/efi/EFI/systemd/grub.efi 

signature 1
image signature issuers:
 - /CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build@suse.de
image signature certificates:
 - subject: /CN=ALP Secure Boot Signkey/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build-alp@suse.de
   issuer:  /CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build@suse.de

Last but not least in chain is kernel - even that must match:

$ sbverify --list /boot/vmlinuz

signature 1
image signature issuers:
 - /CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build@suse.de
image signature certificates:
 - subject: /CN=ALP Secure Boot Signkey/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build-alp@suse.de
   issuer:  /CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build@suse.de

It means:

  • generally you may not mix shim/grub from different distributions (because kernel of your distro may be signed with incompatible key - invalidating chain)
  • even LEAP 16 uses different key than Tumbleweed or LEAP 15 (Yes!) So you may NOT use LEAP 16 bootloader to boot Tumbleweed kernels and vice versa!

So conclusion: use mokutil+sbverify to verify if signature of shim/grub (and possibly kernel matches)

More details can be found in official SUSE docs: https://documentation.suse.com/sles/15-SP6/html/SLES-all/cha-uefi.html

1 Like
3

Thanks very much for the elaborated answer.

Now,

  1. could someone help with the actual question in OP, please?
  2. does Leap 16.0 installer actually performs mokutil commands to enroll its keys into firmware?

Thanks.

4

I don’t believe so. And it should not need to do that.

Leap 16.0 comes with a “shim” which contains the signing key used for Leap 16.0 software. And this should work with secure-boot.

Yes, I can see why have been having problems. That is because of your multi-boot setup. Different distros need different keys.

5

Is it always installed in Leap 16.0 by default even if secure boot in bios is disabled?

6

It should be installed by default on every system booting via UEFI, even with SecureBoot disabled; if not so, you can install afterwards via zypper install shim.
It is not installed if the installer is started in legacy mode on older HW that does not support UEFI booting.

1 Like
7

Yes.

With the old Yast installer, you could change that by disabling secure-boot support during install. I’m not sure if that option is available for Leap 16.0 with the Agama installer.