UEFI MOK screen when rebooting with today's Kernel patch

After applying the Kernel patch released today, at the reboot a blue MOK screen appeared – after continuing the boot the system came up but, the following investigation related to “what is MOK” revealed the following:


 # mokutil --list-new
MokNew is empty
 # mokutil --list-enrolled 
MokListRT is empty
 # mokutil --list-delete 
MokDel is empty
 # mokutil --sb-state 
**SecureBoot disabled**
 # openssl x509 -noout -fingerprint -inform der -in /etc/uefi/certs/
33CEA71B.crt       4659838C-shim.crt  
 # openssl x509 -noout -fingerprint -inform der -in /etc/uefi/certs/33CEA71B.crt 
SHA1 Fingerprint=33:CE:A7:1B:A1:6A:67:BA:D8:6B:93:CB:DA:2E:19:A7:E9:DF:95:66
 # openssl x509 -noout -fingerprint -inform der -in /etc/uefi/certs/4659838C-shim.crt 
SHA1 Fingerprint=46:59:83:8C:82:03:FE:15:52:AD:19:E1:86:09:DB:21:7E:3A:D2:4F
 # 


 > rpm --query --whatprovides /etc/uefi/certs/
kernel-default-5.3.18-lp152.36.1.x86_64
kernel-default-5.3.18-lp152.41.1.x86_64
shim-15+git47-lp152.4.6.1.x86_64
kernel-default-5.3.18-lp152.44.1.x86_64
 > rpm --query --whatprovides /etc/uefi/certs/
33CEA71B.crt       4659838C-shim.crt  
 > rpm --query --whatprovides /etc/uefi/certs/33CEA71B.crt 
kernel-default-5.3.18-lp152.36.1.x86_64
kernel-default-5.3.18-lp152.41.1.x86_64
kernel-default-5.3.18-lp152.44.1.x86_64
 > rpm --query --whatprovides /etc/uefi/certs/4659838C-shim.crt 
shim-15+git47-lp152.4.6.1.x86_64
 > 

“mokutil --pk”, “mokutil --kek”, “mokutil --db” and “mokutil --dbx” are all indicated keys in the various databases – included some the motherboard’s manufacturer …

  • The SHA1 Fingerprints of the Kernel’s certificates located in “/etc/uefi/certs/” are not listed in the MOK databases …

[HR][/HR]And now?

As long as you have secure-boot disabled, it does not much matter.

Your output is a bit puzzling. In my experience, “mokutil --list-enrolled” should show the key that is built into shim.

Maybe you are not using shim. But then you should not be seeing the Mok screen.

Maybe you are booting with the Ubuntu shim. When I last tried that, it did not list the key built into its shim.

In any case, it is fairly normal for a kernel install to install a key in “/etc/uefi/certs”. And a script that runs with the kernel install will then attempt to enroll that key, unless it is already enrolled. If you want to enroll on that blue screen, it does ask for a password. And that should be the root password.

My 15.2 update did not bring up a Mok screen, because that key was already enrolled.

Further info after rebooting – with a UEFI/BIOS secure boot check in between – yes, the motherboard uses the secure UEFI at boot …

  • systemd Journal entries:

Okt 02 19:11:15 xxx kernel: efi: EFI v2.60 by American Megatrends
Okt 02 19:11:15 xxx kernel: efi:  ACPI 2.0=0x514ca000  ACPI=0x514ca000  SMBIOS=0x5b649000  SMBIOS 3.0=0x5b648000  ESRT=0x57cb4418  MEMATTR=0x57d14018 
Okt 02 19:11:15 xxx kernel: secureboot: Secure boot disabled
 .
Okt 02 19:11:15 xxx kernel: secureboot: Secure boot disabled
 .
Okt 02 19:11:15 xxx kernel: ACPI: UEFI 0x00000000514DEAC0 000042 (v01                 00000000      00000000)
 .
Okt 02 19:11:15 xxx kernel: Booting paravirtualized kernel on bare hardware
 .
Okt 02 19:11:15 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 02 19:11:15 xxx kernel: integrity: Loaded X.509 cert 'ASUSTeK MotherBoard SW Key Certificate: da83b990422ebc8c441f8d8b039a65a2'
Okt 02 19:11:15 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 02 19:11:15 xxx kernel: integrity: Loaded X.509 cert 'ASUSTeK Notebook SW Key Certificate: b8e581e4df77a5bb4282d5ccfc00c071'
Okt 02 19:11:15 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 02 19:11:15 xxx kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
Okt 02 19:11:15 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 02 19:11:15 xxx kernel: integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
Okt 02 19:11:15 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 02 19:11:15 xxx kernel: integrity: Loaded X.509 cert 'Canonical Ltd. Master Certificate Authority: ad91990bc22ab1f517048c23b6655a268e345a63'

And, still:


 # mokutil --sb-state 
SecureBoot disabled
 # 

Fresh Leap 15.2 installation – I upgraded the hardware parallel to the Leap 15.2 upgrade – upgraded the old system to Leap 15.2, installed Leap 15.2 on the new hardware, moved the user disks over to the new hardware …

The UEFI BIOS has secure boot enabled …

No Ubuntu on this system – unless Leap 15.2 installed that shim …

For whatever reason, it seems that, the patch script missed that point.
So, is this possibly a correct way to proceed?

 # mokutil --import «some DER»
  • When I find it …

Then reboot and choose “Enroll MOK” at the blue screen – enter the root password – done …

Or, do I simply have to execute “mokutil --enrolled-validation” ?

It looks to me as if secure-boot is disabled in your BIOS.

I have tried disabling with “mokutil --disable-validation”. And, when I do that, I see:


% mokutil --sb-state
SecureBoot enabled
SecureBoot validation is disabled in shim

and that’s not what you are seeing.

Also, if I use

bootctl status

that tells me that secure-boot is enabled.

Okay, those tests were on Tumbleweed. I’ll repeat shortly with Leap 15.2, but I don’t expect anything different.

Shim had a bug - it ignored builtin certificate if no other certificates were enrolled, but Leap 15.2 shim should contain fix for it. It really sounds like older (e.g. Leap 15.0) or non-Leap shim is used.

Except when booting with secure boot disabled. I do not really see why - for all I can tell shim should create MokListRT independently of SB state - but I can easily reproduce it by resetting MokList and disabling Secure Boot.

Hi everyone – weekend over – Saturday was German re-unification (30 years) day and the day after was Sunday …
So:

  • I found this in the openSUSE Reference Guide: <https://doc.opensuse.org/documentation/leap/reference/html/book-opensuse-reference/cha-uefi.html&gt;.
  • I found a MOK DER here: ‘/usr/share/efi/x86_64/’ – “shim-opensuse.der” …
  • Copied the DER file over to ‘/boot/efi/’.
  • Ran “mokutil --import /boot/efi/shim-opensuse.der” – gave it the “root” user’s password – which was wrong – should have used “–root-pw” on the “mokutil” command …
  • Rebooted and got into the UEFI/BIOS setup – took note of the setting for EFI operating system type – was “other” – changed to “Windows 10” because of the Reference Guide text:

There are two ways of getting there. One is to work with hardware vendors to have them endorse a SUSE key, which SUSE then signs the boot loader with. The other way is to go through Microsoft’s Windows Logo Certification program to have the boot loader certified and have Microsoft recognize the SUSE signing key (that is, have it signed with their KEK). By now, SUSE got the loader signed by UEFI Signing Service (that is Microsoft in this case).

  • The UEFI/BIOS shim setting wasn’t changed – it was always pointing to the “secure-boot openSUSE” shim …
  • On saving and exiting from the UEFI/BIOS setup a blue screen came up asking if the openSUSE shim could be trusted – answered “yes” …
  • A password wasn’t needed …
  • The machine is now running with the following information regarding UEFI Secure Boot:

 # mokutil --sb-state
SecureBoot enabled
 # od -An -t u1 /sys/firmware/efi/vars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c/data 
   1
 # mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 46:59:83:8c:82:03:fe:15:52:ad:19:e1:86:09:db:21:7e:3a:d2:4f
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
        Validity
            Not Before: Aug 26 16:12:07 2013 GMT
            Not After : Jul 22 16:12:07 2035 GMT
        Subject: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:de:df:61:92:7a:a4:fe:83:d1:7d:3b:68:0e:b1:
                    a7:f0:4e:92:93:fc:47:3e:70:2d:4e:88:dc:9a:9e:
                    fa:33:b4:a6:db:0e:23:c1:0d:a8:c1:d5:65:04:84:
                    04:ff:3a:48:18:4f:39:32:e4:ca:4e:f9:04:9e:9f:
                    0f:cd:20:5d:61:ab:a7:00:d8:a5:ff:2b:7f:be:e8:
                    47:c3:2f:5b:02:c8:bb:de:8e:1a:e9:46:d3:86:ef:
                    ff:88:99:90:eb:10:89:b8:8b:3f:3e:a8:07:c6:55:
                    7a:6e:d3:5f:fc:83:3c:3d:16:ed:26:c5:13:73:92:
                    b1:70:1e:22:95:c8:00:6c:25:76:46:f1:a2:d9:d0:
                    b0:98:68:0f:a7:2d:b1:0d:67:89:ca:94:4a:ea:12:
                    c5:91:55:76:7f:6c:7a:2e:f9:18:89:9f:f8:f4:24:
                    43:d5:35:6a:cb:00:0e:2e:ed:4b:e2:5d:09:d8:1b:
                    97:70:99:9e:5a:6f:a6:81:a8:9d:a9:58:76:7d:69:
                    71:82:d3:ba:3a:96:43:9b:f0:da:15:c6:4e:e9:c8:
                    15:b9:e9:cb:c7:e4:71:ce:ea:10:1b:6b:c4:2a:70:
                    01:a9:52:b4:17:de:00:52:cf:7d:e4:fd:0f:4d:03:
                    18:b2:90:28:d4:6f:c4:ae:56:bc:36:60:49:46:8b:
                    6b:0b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                68:42:60:0D:E2:2C:4C:47:7E:95:BE:23:DF:EA:95:13:E5:97:17:62
            X509v3 Authority Key Identifier: 
                keyid:68:42:60:0D:E2:2C:4C:47:7E:95:BE:23:DF:EA:95:13:E5:97:17:62
                DirName:/CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org
                serial:01

            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
         8a:a3:89:c2:8e:d9:f9:82:0b:f3:33:ce:e9:19:17:17:a3:65:
         80:cd:33:ae:06:51:56:29:b6:38:87:7b:f4:9d:fc:28:8e:aa:
         e0:53:12:0e:3a:60:c7:06:d8:3a:61:76:3b:77:08:f4:94:a4:
         8c:7c:47:3a:99:d8:84:9b:17:cc:20:62:2e:e2:76:e4:c6:36:
         0d:26:e9:2e:53:35:0a:fb:3a:35:93:45:c3:93:82:c1:0b:f3:
         08:e9:57:1f:59:37:a9:d0:6c:69:fb:68:ea:7f:3b:af:d3:f7:
         59:27:8e:d4:c7:96:73:f4:0c:0a:f7:3e:e4:af:6c:8c:c7:7a:
         6f:09:79:f4:41:1f:e3:6f:11:fb:3e:6c:b1:a0:7b:e4:92:b7:
         ca:f9:32:f5:de:c3:b0:73:7d:e3:b3:82:5d:cd:ec:61:dc:fe:
         0c:3e:c6:b5:e7:6c:2d:5d:92:73:ff:ed:aa:6a:a9:9b:66:9e:
         5e:3a:6d:70:b0:31:c0:ce:df:2f:21:10:68:0c:87:f3:77:a0:
         33:31:0a:0f:15:f6:ee:32:88:c5:9a:53:71:cd:0d:1a:a1:28:
         89:d0:bf:f6:56:ac:4b:3b:36:06:2b:01:c5:eb:e5:dc:72:83:
         3d:94:ac:28:83:13:fb:c1:5d:27:9c:13:f6:32:5f:f6:1f:4a:
         b7:3e:53:8a
 # journalctl --this-boot | grep -iE 'secure|efi' | grep -iEv 'clocksource|efifb|tsc'
Okt 05 08:17:52 xxx kernel: efi: EFI v2.60 by American Megatrends
Okt 05 08:17:52 xxx kernel: efi:  ACPI 2.0=0x514ca000  ACPI=0x514ca000  SMBIOS=0x5b649000  SMBIOS 3.0=0x5b648000  ESRT=0x57cb3018  MEMATTR=0x57d14018 
Okt 05 08:17:52 xxx kernel: secureboot: Secure boot enabled
Okt 05 08:17:52 xxx kernel: Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
Okt 05 08:17:52 xxx kernel: secureboot: Secure boot enabled
Okt 05 08:17:52 xxx kernel: ACPI: UEFI 0x00000000514DEAC0 000042 (v01                 00000000      00000000)
Okt 05 08:17:52 xxx kernel: Registered efivars operations
Okt 05 08:17:52 xxx kernel: fb0: EFI VGA frame buffer device
Okt 05 08:17:52 xxx kernel: EFI Variables Facility v0.08 2004-May-17
Okt 05 08:17:52 xxx kernel: Loaded X.509 cert 'openSUSE Secure Boot Signkey: c8bdc7ac1a1d85966217fd93ebfc14f4a200b814'
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 05 08:17:52 xxx kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:MokListRT
Okt 05 08:17:52 xxx kernel: integrity: Loaded X.509 cert 'openSUSE Secure Boot CA: 6842600de22c4c477e95be23dfea9513e5971762'
Okt 05 08:17:52 xxx kernel: fb0: switching to amdgpudrmfb from EFI VGA
Okt 05 08:17:53 xxx kernel: pstore: Efi pstore disabled, enforce via pstore.backend=efi
Okt 05 08:17:53 xxx kernel: pstore: Only enable efi based pstore when you know what you are doing
Okt 05 08:17:54 xxx systemd[1]: Mounting /boot/efi...
Okt 05 08:17:54 xxx systemd[1]: Mounted /boot/efi.
 # 

Note Bene:

  • The Mainboard is an ASUS PRIME B450-Plus with an AMD Ryzen 5 3400G CPU …
  • “mokutil --pk” reveals that, an ASUSTeK MotherBoard PK Certificate is present on the Mainboard …
  • “mokutil -kek” reveals that, an ASUSTeK MotherBoard KEK Certificate and, a Microsoft KEK as follows and, a Canonical KEK as follows, are present on the Mainboard …

        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
        Validity
            Not Before: Jun 24 20:41:29 2011 GMT
            Not After : Jun 24 20:51:29 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011

        Issuer: C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
        Validity
            Not Before: Apr 12 11:12:51 2012 GMT
            Not After : Apr 11 11:12:51 2042 GMT
        Subject: C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority

Sorry, the grep on the systemd Journal lost some of the “integrity” information:


Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 05 08:17:52 xxx kernel: integrity: Loaded X.509 cert 'ASUSTeK MotherBoard SW Key Certificate: da83b990422ebc8c441f8d8b039a65a2'
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 05 08:17:52 xxx kernel: integrity: Loaded X.509 cert 'ASUSTeK Notebook SW Key Certificate: b8e581e4df77a5bb4282d5ccfc00c071'
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 05 08:17:52 xxx kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 05 08:17:52 xxx kernel: integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:db
Okt 05 08:17:52 xxx kernel: integrity: Loaded X.509 cert 'Canonical Ltd. Master Certificate Authority: ad91990bc22ab1f517048c23b6655a268e345a63'
Okt 05 08:17:52 xxx kernel: integrity: Loading X.509 certificate: UEFI:MokListRT
Okt 05 08:17:52 xxx kernel: integrity: Loaded X.509 cert 'openSUSE Secure Boot CA: 6842600de22c4c477e95be23dfea9513e5971762'

Finally got around to applying the said Kernel patch yesterday afternoon to my Lenovo G505s Laptop – not so new …

  • Yes, “blue screen at boot with a timeout” – you need to be quick to catch it …
  • “Arrow down” to the correct choice – “Enroll MOK” – “Arrow down” to make the correct choice – enter the password of the user “root” – wait for the reboot …
  • The systemd journal entries for UEFI Secure Boot were OK before applying the Kernel patch (secureboot: Secure boot enabled) and “mokutil” found one (1) enrolled openSUSE certificate.
  • After applying the Kernel patch, everything was still OK except that, “mokutil” now displayed two (2) enrolled openSUSE certificates – possibly, one of them can be deleted …

[HR][/HR]How on earth is a “newbie” going to handle this situation?

  • Do we need to press for an urgent update to the openSUSE documentation? :question:

Two is correct, I think. One of those is built into “shim”, and the other is what you just added.

You can compare with “/etc/uefi/certs” – those are the certificates you should see.

If the user gets it wrong at the reboot after the Kernel patch then at least one of the certificates will not be enrolled …

  • I found one DER file – ‘/usr/share/efi/x86_64/shim-opensuse.der’ …
  • But I missed ‘/usr/share/efi/x86_64/grub.der’ – I’ll try to enrol that one as well and, compare to what’s on the Laptop …

[HR][/HR]The question, “What happens to the poor unsuspecting users?” remains … :question:

Most likely nothing as long as user is using openSUSE shim.