2

Good evening, after searching on google I didn't find the answer to my question.

When installing a distribution such as Ubuntu with secure boot activated, the installer creates a MOK key in the NVRAM which can be seen with ‘mokutil -l ’.

Later, I decide to change distribution to Fedora, the installer will insert its own key in the NVRAM that I can see with ‘mokutil -l’ but the Ubuntu key is not visible from Fedora.

Does this mean that each distribution creates its own database in NVRAM? Is it possible to see the previously installed keys of other distributions? To clean NVRAM of these old MOKs from old distributions?

This is for security reasons, but also to save space. As the amount of NVRAM is very small, isn't there a risk that it will be full if you install frequently?

Restoring the Secure Boot factory settings in the UEFI resets the PEK, KEK, DB and DBX keys but does not seem to remove the MOK keys in my case.

Improve this question
2
  • See my answer here. I believe you can use the MokUtil program to view and alter the key database. Commented May 29, 2024 at 20:56
  • I do not see the database from past installations with moktuil, only the current one. Commented May 30, 2024 at 6:59

1 Answer 1

Reset to default
4

The concept of MOK is not officially part of Microsoft's Secure Boot. It's implemented by Shim, a special loader that actually overrides the firmware's Secure Boot handling – it has its own signature verification code that allows MOK-signed loaders to completely bypass the built-in SB verification.

Therefore the MOK database is stored as an ordinary EFI NVRAM variable named MokList, with the only protection being that it's marked as "visible to boot services only", i.e. you can see it from within the EFI Shell environment but not through /sys/firmware/efi/efivars from a running OS. (Shim creates a read-only copy of it named MokListRT for the Linux mokutil to see.)

EFI variables are namespaced by vendor GUID, so in theory two copies of Shim (coming from different sources) could have independent MokList variables, and only the one supported by Fedora's Shim would be visible as MokListRT from within Fedora. (I don't know if that's actually the case.) A new Ubuntu installation would then see the previous Ubuntu MOK.

A very manual way to clean things up is to download EFI Shell and configure the system to boot into it. From there you might be able to use Ubuntu's MokUtil.efi – or run dmpstore -b to get a list of all EFI variables (including the Boot Services-only ones), looking for any instance of 'Mok', then delete them one by one using dmpstore -d <name> -guid <guid>.

In the dmpstore output, NV mean non-volatile (e.g. MokStore is NV whereas MokStoreRT is not NV and only exists in temporary RAM); BS means available to boot services (EFI apps); and RT maeans available to runtime services (visible by OS).

Improve this answer
14
  • Thank you for your reply. Should a reset of the efi delete the MOK variables? Commented May 30, 2024 at 10:45
  • 1
    I think it might depend on what kind of reset, but generally I'd say yes. You can test by comparing the list from Linux (before/after) or even creating your own variables and checking if they disappear after a reset. Commented May 30, 2024 at 11:40
  • I checked the efi Shell with 'dmpstore -b'; no trace of MOK. Yet I can still boot with secure boot enabled. Commented May 30, 2024 at 14:12
  • 1
    Yes, it is stock Fedora and Ubuntu. The Fedora's vendor key is not written in the NVRAM ? $ mokutil -l 2bb010e24d fedoraca Commented May 30, 2024 at 14:41
  • 1
    [MokListRT] 2bb010e24d fedoraca [MokListXRT] 0000000000 (sha256) Commented May 30, 2024 at 15:33

You must log in to answer this question.