43

Upon installing Nvidia drivers I was promoted to set up a MOK password or third party drivers may not work properly, so I created one. After reboot I was presented with a blue MOK management screen with a few options in it, the first one being continue boot. So I chose this and when boot was finished, my second monitor wasn't being recognized. Remembering reading something about secure boot when initially prompted about MOK, I booted into the BIOS and turned secure boot off. Now I have my second screen back. Several questions come to mind.

  1. First, what is MOK?
  2. Do I need it, and if not, how do I get rid of it?
  3. Was losing recognition of my second screen due to installing Nvidia drivers, or setting up MOK?
  4. Can I just keep secure boot off?
Improve this question
2
  • 2
    When booting with the MOK blue screen, you should have chosen "iinstall key", and then enter the password you have chosen. That way, it would have worked with "Secure Boot" enabled, and nvidia drivers
    – solsTiCe
    Commented Feb 16, 2021 at 9:00
  • 1
    I installed ubuntu 22.04.3 LTS on hp omen 40L. After reboot I could not enroll/hash keys at MOK screen. Boot did not work. After some basic initialization of the system's hard disk I got no messages and a "freeze". Boot in recovery mode worked. Main difference seems "gfxmode $linux_gfx_mode" - so graphics. Then I installed 3rd party drivers (enabled at install) via "sudo ubuntu-drivers devices" and "sudo ubuntu-drivers autoinstall". I got prompted to create a MOK and associated pwd. At next boot, I got MOK screen again and now could "Enroll MOK" - had to give pwd. Regular boot works now. HTH
    – Thomas Preu
    Commented Aug 13, 2023 at 18:10

2 Answers 2

Reset to default
25

ad 1)

MOK (Machine Owner Key) is about securing the boot process by only allowing approved OS components and drivers to run. MOK must be implemented by the "BIOS" - or some startup code inside the computer, anyway.

The main idea is that only code which is signed is allowed to run while loading the operating system (OS). Once that is booted, the OS can take over responsibility from the BIOS for securing the system.

The MOK system uses public key cryptography, which means that you can create a key pair, then sign, with your private/secret key, all components that are allowed to run. This includes the GRUB boot loader itself. The BIOS then uses your public key (you need to install it) to check signatures before running the code.

Here are some docs on Secure Boot and MOK

The beauty of MOK, in my personal opinion, is that you can create the keys yourself and sign those components that you trust. In the past, the EFI BIOS had only Microsoft's public key installed and they were hesitant to sign Linux boot loaders :-) That's why you needed SHIM in the past (a go-between between EFI BIOS and GRUB).

All Secure Boot methods hope to secure the system from hackers and viruses by guaranteeing a cleanly booted system which is not tampered by malware. If startup code or drivers have been tampered with, it is detected so that you can act accordingly. There are not many options to defend your machine if the attacker has physical access to your computer ("evil maid attack") - even if for example your disk with all the important data is encrypted an attacker can modify the boot code to read your password while you enter it, then transmit or store it for them to read later. Secure Boot works against such a modification.

Kyle Rankin has done a lot of work on securing the boot process for the Librem range of Laptops, and here is a good article on his work. I believe it is well worth reading even if it is not directly applicable to your system - the idea is just the same.

ad 2) and 4)

Do you need MOK and Secure Boot? Not if you will never be successfully attacked by a hacker, especially one who might have physical access to your laptop or gains root access from the Internet through browser/office/Linux bugs. As for disabling, you have done the right thing - disable Secure Boot in your BIOS.

Improve this answer
2
  • Thank you for responding so quickly, I'll read up on the docs.
    – VernonB
    Commented Aug 13, 2019 at 19:59
  • 2
    Most firmware still "only" have microsoft public key (I mean, unless you buy a Librem laptop, everybody else cares to make Windows fully happy). Be it in the past or today, you could always customize them to add or remove keys then. Shim is only needed if you don't want users having to bother with the system's own messy utilities.
    – mirh
    Commented Aug 13, 2019 at 20:24
9

ad 3)

with Secure Boot in effect, only kernel modules with valid signatures will be allowed. As the MOK installation process was not actually completed, the signature check on the Nvidia modules failed, and as the Nvidia module installation process had probably already blacklisted the in-kernel nouveau drivers, the system most likely fell back to the un-accelerated efifb display driver, which only supports whatever displays the firmware had already set up.

In order to protect the system from unauthorized modification of the MOK, the MOK installation process will request the firmware to store the MOK in such a way that it will only be accessible at boot time - not when any OS is actually running. Because of this, the MOK installation process requires a reboot.

First, the MOK is created and prepared for installation while the OS is running, and a one-time password is created to protect the second phase of the installation process. Then, the system is rebooted, and the shimx64.efi will detect that a MOK installation process has been started, and shows the blue MOK Manager screen at boot. At that point, you should select the "install key" option and confirm it by entering the one-time password that was set before the reboot. That password will never again be required: if the MOK installation was successful, the kernel module management tools will be able to automatically use the MOK when needed, or if it failed, the MOK installation process will need to be started over from the beginning.

Initially, Secure Boot firmware will only accept bootloader *.efi files (which must use the Windows-style PE32/PE32+ binary format, rather than the ELF format Linux uses) that are either specifically whitelisted by cryptographic hash or signed by one of the Secure Boot certificates in the firmware NVRAM. The shimx64.efi will add the Linux distribution's signing certificate and optionally the MOK certificate to the list of allowed certificates (non-persistently).

This will allow shimx64.efi to load the grubx64.efi bootloader and the distribution kernel, which are signed with the Secure Boot signing key of that particular Linux distribution. When built for UEFI, the Linux kernel can include an UEFI boot stub which will make the kernel look like a PE32+ binary, so the kernel can also be signed in a Secure Boot-compatible way.

The Secure Boot specification requires that the kernel must maintain the requirement to have all kernel code signature-checked before executing it, or else any non-compliant kernels may be blacklisted by future Secure Boot-compliant firmware versions. Therefore, the kernel will also signature-check any kernel modules it will load. For this purpose, the kernel axiomatically trusts the signing key it was built with. Distribution kernels usually add the Secure Boot accepted keys to their whitelist (see keyctl list %:.builtin_trusted_keys and keyctl list %:.secondary_trusted_keys in modern Linuxes, or keyctl list %:.system_keyring in older versions) - this will include the MOK if one is set.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .