MOK enrollment silently fails #105

jrmrjnck · 2017-11-21T01:06:19Z

I'm trying to enroll a new MOK, but it doesn't take effect even though none of the tools show any error. It may be a UEFI implementation bug, but the error checking in MokManager seems decent, so I'm not sure what could be failing.
OS: Fedora 27
HW: HP Elitebook 840 G2
BIOS: M71 v 1.21 (latest available)

mokutil --import mok.der
verify MOK is set to be enrolled via --list-new, and view new EFI vars with efivar -l
Reboot
MokManager is loaded, and I go through the enrollment menus. New MOK is present, and password is accepted. No errors are shown, and I select option to reboot.
Reboot to OS
mokutil --list-enrolled does not show new MOK, only the existing Fedora Secure Boot CA key. The new MOK is no longer shown under --list-new and the MokNew/MokAuth vars are gone.

The text was updated successfully, but these errors were encountered:

lcp · 2017-11-21T04:17:38Z

Would it work after turning off Secure Boot? Just wonder if the firmware clear all BS variables it doesn't know when Secure Boot is enabled...

jrmrjnck · 2017-11-21T05:46:25Z

No, I've tried the steps with Secure Boot enabled and disabled, and the behavior is the same (except for an extra message when MokManager loads saying that secure boot is disabled).

lcp · 2017-11-22T03:57:27Z

That sounds bad :-(
We probably have to contact the firmware vendor for the details. Would you mind to provide the result of dmidecode?

rvp-nl · 2018-02-03T10:50:10Z

Hi too have this problem on a HP Elitebook 8470p.

SecureBoot is enabled. I did the following:

sudo efivar -l > efivars.txt.1
sudo mokutil --import ./MOK.der
sudo mokutil --list-new
sudo efivar -l > efivars.txt.2
diff efivars.txt.1 efivars.txt.2
sudo reboot
(mokmanager starts, follow enrollment)
sudo cat /proc/keys

Before reboot the key is listed as new. MokManager.efi is then started and shows the certificate. It enrolls without errors and warnings. After reboot however, the key is not listed in /proc/keys.

This is with 0.3.0-0ubuntu4 (Ubuntu 17.10)

lcp · 2018-02-07T06:59:46Z

The enrolled keys are stored in the UEFI variable and viewable with "mokutil -l" which reads data from "/sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23".

rvp-nl · 2018-02-07T23:19:20Z

There is no sign of my enrolled MOK in "/sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23". It only contains the "Canonical Ltd. Master Certificate Authority" key.

Could it be that MokManager tries to save the MOK in UEFI vars but fails silently? The HP EliteBook 8470p BIOS is from 2012. I read similar reports with some other HP laptops. Furthermore, I suppose that not many people are trying to enroll their own MOK?

lcp · 2018-02-08T02:44:59Z

It could be either variable writing failed silently or the firmware cleared the variables it doesn't know. I heard some firmware vendor did the later before.

rvp-nl · 2018-02-12T12:01:21Z

Ok, too bad... so it seems that I will not be able to use a MOK for driver signing on this laptop :-(

hedayat · 2018-04-19T14:12:25Z

I've the same problem with HP ZBook 15 Workstation. The last BIOS/UEFI update is from 2018, so the firmware is not old.

I've exactly the same problem: mokutil seems to work fine. Shim prompts me to enroll the key. I can view the key info and it is OK. Shim verbose mode is enabled. I tell it to enroll the key, it received the password. There is no errors.

But, the key is not added.

I guess if the variables were cleared, shim would not see a new key should be enrolled at all, correct?! Also, it seems that Fedora own key is already added to 605dab50-e046-4300-abb6-3dd810dd8b23-MokListRT var; or not? mokutil -l shows Fedora key, but not mine.

lcp · 2018-04-20T03:13:55Z

The attribute of the mok request is BS+RT+NV while the attribute of MokList is BS+NV, so the firmware may just clear BS+NV variables.

As for the fedora key, shim copies the built-in key to MokListRT for every booting, so the built-in key always shows in mokutil -l.

hedayat · 2018-04-20T16:46:12Z

Thank you for clarification. Is there anything I can do to debug the problem even more? Is there any workaround for enrolling the key, so that we can get custom kernel modules verified? (without enrolling our own keys in UEFI itself instead of factory ones)?

lcp · 2018-04-26T03:56:51Z

To be honest, I don't have a good idea now since I don't have the contact to HP firmware team :-\

rvp-nl · 2018-04-26T08:14:56Z

I've the same problem with HP ZBook 15 Workstation. The last BIOS/UEFI update is from 2018, so the firmware is not old.

Is this HP ZBook 15 a recent laptop? The BIOS of my HP Elitebook 8470p is also from 2018, thanks to the Meltdown and Spectre bugs. But, the laptop is still from 2013 and MOK enrollment doesn't work with the new BIOS either.

hedayat · 2018-04-26T13:42:07Z

No, it is probably 3 or 4 years old.
But they actually did fix at least one other UEFI bug I had with the older BIOS version, and their BIOS changelog of latest version also mentions that it had UEFI fixes; therefore, it'd not be surprising if their 2018 laptops also suffer from this problem.

I just thought that you mean you BIOS is old :)

lcp · 2018-05-04T01:58:39Z

@strangeflower @hedayat My colleague helped me to contact the HP firmware team, and they are looking into the issue. Would you mind to provide the BIOS version?

hedayat · 2018-05-04T08:20:20Z

BIOS Information
        Vendor: Hewlett-Packard
        Version: L70 Ver. 01.40
        Release Date: 01/26/2018
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 8192 kB
        Characteristics:
                PCI is supported
                PC Card (PCMCIA) is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                EDD is supported
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                ACPI is supported
                USB legacy is supported
                Smart battery is supported
                BIOS boot specification is supported
                Function key-initiated network boot is supported
                Targeted content distribution is supported
                UEFI is supported
        BIOS Revision: 1.40
        Firmware Revision: 148.86

rvp-nl · 2018-05-04T10:33:10Z

My laptop (Elitebook 8470p) has:
System BIOS version 68ICF Ver. F.70
BIOS Date is 02/13/2018

dmidecode output:

BIOS Information
	Vendor: Hewlett-Packard
	Version: 68ICF Ver. F.70
	Release Date: 02/13/2018
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 5120 kB
	Characteristics:
		PCI is supported
		PC Card (PCMCIA) is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		Smart battery is supported
		BIOS boot specification is supported
		Function key-initiated network boot is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 15.112
	Firmware Revision: 66.56

lcp · 2018-05-07T02:35:55Z

Thanks! I provided the information to HP firmware team. Hope we can find the root cause.

rvp-nl · 2018-05-07T07:59:24Z

@lcp That's great, thanks for putting effort into this!

lcp · 2018-05-09T07:16:00Z

I wrote a test program and will provide it to HP to reproduce the issue. Here is the logic of the program:

If MokList doesn't exist, it writes a key into the variable and resets the system.
If MokList exists, it shows a prompt to ask if the variable should be deleted or not.

For a functional system, it will set MokList at the first boot and ask the user to delete MokList after reset.

If anyone is willing to test the program, here are the links:

Source code:
https://github.com/lcp/uefi-fun/tree/master/WriteMok
Binary:
https://github.com/lcp/uefi-fun/blob/master/WriteMok/WriteMok.efi

hedayat · 2018-05-09T21:24:55Z

I tested it, and it always says that MokList doesn't exist (as expected!).

rvp-nl · 2018-05-09T22:30:00Z

I also ran a test. WriteMok always reports that the MokList doesn't exist.

BTW, I disabled SecureBoot before testing because WriteMok.efi is not signed.

lcp · 2018-05-10T02:37:25Z

Per HP firmware team, the implementation of SetVariable() in those laptops couldn't handle EFI_VARIABLE_APPEND_WRITE properly. It would just return EFI_SUCCESS without writing the content to the flash. We previously checked EFI_INVALID_PARAMETER for some Lenovo machines but this is not enough for your HP machines :-
https://github.com/rhboot/shim/blob/14/MokManager.c#L911-L919

So, we should drop EFI_VARIABLE_APPEND_WRITE to avoid faulty implementation.

Here is the updated WriteMok:
https://github.com/lcp/uefi-fun/blob/master/WriteMok/WriteMok2.efi
Source code:
https://github.com/lcp/uefi-fun/blob/master/WriteMok/WriteMok2.c

If it works, I'll submit a patch to remove EFI_VARIABLE_APPEND_WRITE.

hedayat · 2018-05-10T12:56:17Z

Thanks it works.

BTW, does it mean that they don't care to fix their UEFI to at least return an error code in this case?! This is certainly a bug!

rvp-nl · 2018-05-10T19:09:22Z

It works on my laptop too. In Ubuntu 17.10 I can see the key:

# sudo keyctl list %:.secondary_trusted_keys
...
Justatest: Testing: f34e69dc95fecc4c6610b8a2fc6ff69a48c91062
...

I see the certificate is encoded in WriteMok.c in ca_list_bin. How did you encode this? I would like to try and install my own MOK :-)

lcp · 2018-05-11T02:08:31Z

@hedayat I'm not sure if they will fix it or not, but it's faster to change MokManager than to wait for the firmware update.

@strangeflower The certificate is created randomly in my machine, so you'd be better to run WriteMok2 again and delete it :) The ca_lis_bin is a x509 certificate in DER format with the signature database header. The binary can be generated with efisiglist from pesign and then you can use "xxd -i" to convert the binary file into a C array.

I'll write a patch for MokManager and add the comment to remind the developers not to use EFI_VARIABLE_APPEND_WRITE.

When writing MokList with EFI_VARIABLE_APPEND_WRITE, some HP laptops may just return EFI_SUCCESS without writing the content into the flash, so we have no way to detect if MokList is updated or not. Now we always read MokList first and write it back with the new content. rhboot#105 Signed-off-by: Gary Lin <glin@suse.com>

rvp-nl · 2018-05-14T22:46:42Z

I patched shim v14 (v15 and later won´t compile on my machine) and built it on Ubuntu 17.10 with:

ARCH_LDFLAGS="-L /usr/lib" LIBDIR=/usr/lib EFI_PATH=/usr/lib make mmx64.efi

MokManager (mmx64) enrolls the MOK key successfully and driver signing works.

hedayat · 2018-05-15T08:27:48Z

I can second that, as I failed using efisiglist (resulted in corrupted MokList apparently! :P). I tried shim master.

lcp · 2018-05-16T02:02:04Z

I forgot to mention that you may need this pesign patch.
rhboot/pesign#40

When writing MokList with EFI_VARIABLE_APPEND_WRITE, some HP laptops may just return EFI_SUCCESS without writing the content into the flash, so we have no way to detect if MokList is updated or not. Now we always read MokList first and write it back with the new content. #105 Signed-off-by: Gary Lin <glin@suse.com>

mahsoommoosa42 · 2018-12-09T18:50:14Z

I'm new to all this. So, forgive me if I saw anything stupid. My key is showing up in mokutil --list-enrolled. But, it hasn't shown up in /proc/keys. So, how should i proceed to get around this error?

lcp · 2018-12-11T03:42:47Z

If the key shows in mokutil -l, the key already exists in MokListRT. /proc/keys is managed by linux kernel. Either the kernel didn't enroll MOK in the keyring, or you just forgot to use root privilege to check the keyring.

When writing MokList with EFI_VARIABLE_APPEND_WRITE, some HP laptops may just return EFI_SUCCESS without writing the content into the flash, so we have no way to detect if MokList is updated or not. Now we always read MokList first and write it back with the new content. #105 Signed-off-by: Gary Lin <glin@suse.com> Upstream-commit-id: f442c84

jhngrn · 2021-09-04T01:07:55Z

I'm happy that I found this thread. Please see my StackExchange post ?

I have my public DER with mokutil --import DER enter the password twice and on reboot there isn't an opportunity to enter the password a third time.

hollowaykeanho · 2021-12-18T16:05:07Z

Either the kernel didn't enroll MOK in the keyring

Might sound silly but, how do we verify & enable this? Operating system configurations instead of manual kernel compilation.

From Debian.

shawn-eary · 2022-03-14T19:55:55Z

The enrolled keys are stored in the UEFI variable and viewable with "mokutil -l" which reads data from "/sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23".

I don't seem to have a /sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23 file and I keep getting the

root@myMachineName:/sys/firmware/efi/efivars# mokutil -l
MokListRT is empty

error. Maybe I need to do mokutil --reset to get that file?

shawn-eary · 2022-03-14T20:03:47Z

The enrolled keys are stored in the UEFI variable and viewable with "mokutil -l" which reads data from "/sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23".

I don't seem to have a /sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23 file and I keep getting the
root@myMachineName:/sys/firmware/efi/efivars# mokutil -l
MokListRT is empty
error. Maybe I need to do mokutil --reset to get that file?

mokutil --reset

Didn't do me any good. I still can't enroll keys via mokutil and the reboot process that jrmrjnck describes.

tomty89 · 2022-05-31T08:35:00Z

Similar issue here on an AMD lenovo laptop S540-13ARE with Phoenix UEFI firmware. mokutil import works (MokManager launched, direct enroll option shown, password asked, no error shown after entering password) but nothing actually get enrolled at the end (not even the fedora CA). mokutil list-enrolled literally returns nothing at all after reboot. No MOK item found in efivars either.

tomty89 · 2022-05-31T14:28:51Z

Oh never mind. I copied fbx64.efi to /EFI/BOOT/ while I do not have a bootx64.csv there (and really just need shim to load grubx64.efi), that's why it didn't work. (And the RT efivars will only show up when shim successfully helped booting the OS).

P.S. Couldn't / shouldn't shim / fbx64.efi be made to load grubx64.efi when no valid bootx64.csv is found?

lepz0r · 2024-04-03T08:14:58Z

For me (Lenovo ThinkPad T480) it seems the MOK is enrolled as it shown during setup mode & MOK manager verbose log but it's seems the MOK db is always ignored no matter if I set --use-db or --ignore-db

lcp mentioned this issue May 11, 2018

MokManager: Stop using EFI_VARIABLE_APPEND_WRITE #129

Merged

MOK enrollment silently fails #105

MOK enrollment silently fails #105

Comments

jrmrjnck commented Nov 21, 2017

lcp commented Nov 21, 2017

jrmrjnck commented Nov 21, 2017

lcp commented Nov 22, 2017

rvp-nl commented Feb 3, 2018

lcp commented Feb 7, 2018

rvp-nl commented Feb 7, 2018

lcp commented Feb 8, 2018

rvp-nl commented Feb 12, 2018

hedayat commented Apr 19, 2018

lcp commented Apr 20, 2018

hedayat commented Apr 20, 2018

lcp commented Apr 26, 2018

rvp-nl commented Apr 26, 2018

hedayat commented Apr 26, 2018

lcp commented May 4, 2018

hedayat commented May 4, 2018

rvp-nl commented May 4, 2018 • edited Loading

lcp commented May 7, 2018

rvp-nl commented May 7, 2018

lcp commented May 9, 2018

hedayat commented May 9, 2018

rvp-nl commented May 9, 2018

lcp commented May 10, 2018

hedayat commented May 10, 2018

rvp-nl commented May 10, 2018 • edited Loading

lcp commented May 11, 2018

rvp-nl commented May 14, 2018 • edited Loading

hedayat commented May 15, 2018

lcp commented May 16, 2018

mahsoommoosa42 commented Dec 9, 2018

lcp commented Dec 11, 2018

jhngrn commented Sep 4, 2021

hollowaykeanho commented Dec 18, 2021

shawn-eary commented Mar 14, 2022

shawn-eary commented Mar 14, 2022

tomty89 commented May 31, 2022 • edited Loading

tomty89 commented May 31, 2022 • edited Loading

lepz0r commented Apr 3, 2024 • edited Loading

rvp-nl commented May 4, 2018 •

edited

Loading

rvp-nl commented May 10, 2018 •

edited

Loading

rvp-nl commented May 14, 2018 •

edited

Loading

tomty89 commented May 31, 2022 •

edited

Loading

tomty89 commented May 31, 2022 •

edited

Loading

lepz0r commented Apr 3, 2024 •

edited

Loading