search

rhboot / shim

UEFI shim loader
Other
867 stars 293 forks source link

MOK enrollment silently fails #105

Open jrmrjnck opened 6 years ago

jrmrjnck commented 6 years ago

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)

  1. mokutil --import mok.der
  2. verify MOK is set to be enrolled via --list-new, and view new EFI vars with efivar -l
  3. Reboot
  4. 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.
  5. Reboot to OS
  6. 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.
lcp commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

hedayat commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

rvp-nl commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago 
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 commented 6 years ago

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 commented 6 years ago

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

rvp-nl commented 6 years ago

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

lcp commented 6 years ago

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

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 commented 6 years ago

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

rvp-nl commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

rvp-nl commented 6 years ago

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 commented 6 years ago

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

lcp commented 6 years ago

I forgot to mention that you may need this pesign patch. https://github.com/rhboot/pesign/pull/40

mahsoommoosa42 commented 5 years ago

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 commented 5 years ago

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.

jhngrn commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 7 months ago

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