Debian Secure Boot: To be, or not to be, that is the question!

🔮🧙‍♀️: If you’re here reading this article, it’s because:

A. You’ve encountered a huuuuugeeee problem with your Linux OS because of Secure Boot (most probably your problem is goodbye 🫡 nvidia kernel module (a.k.a driver) after booting with Secure Boot enabled).

B. You’re a security freak and firmly believe that if there’s a security mechanism, it is absolutely UNACCEPTABLE not to use it on your OS! <--- I am here.

If you fall under category B —or if my crystal ball 🔮 is glitching—here are some scenarios that might lead you to start googling "How to Enable Secure Boot on OS X (Debian, I hope)".

While all my articles are about Debian, this article can still be useful for other Linux OSs since it’s focused on the logic behind Secure Boot.

NB! In this article, I will show how to install NVIDIA drivers on a setup with Secure Boot enabled. However, I will not go into details about the NVIDIA driver installation peculiarities, as NVIDIA drivers in this article serve as an example of how to install kernel modules signed for Secure Boot.

So, you’re using your OS, enjoying it, 🦄🌈… and then something happens that pushes you to start digging through forums about Secure Boot. Two possible scenarios:

• You’re using a dual boot setup with Windows and recently upgraded to Windows 11. Windows 11's minimum requirements include Secure Boot. As a result, you disable Secure Boot in the BIOS to log into your Debian system, then re-enable it in the BIOS to log back into Windows. And you are fed up doing this.


• To install and play a video game (like Valorant, FIFA), your system needs Secure Boot enabled. In this case, Secure Boot acts as part of the game’s anti-cheat mechanisms.

What is Secure Boot?

UEFI Secure Boot (SB) is a verification mechanism for ensuring that code launched by a computer's UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process, before the operating system has been loaded. ()

However, BIOS is a legacy (term used for an "outdated" software that is still in use) for years. If you’re using a relatively modern machine, what you’re actually using is UEFI—the successor to BIOS, designed to overcome its technical limitations. Some operating systems, like Windows 11, have completely dropped support for BIOS firmware and won’t run on older hardware that relies on it. Additionally, all Intel platforms have also discontinued support for BIOS entirely. ()

Myth 1: Secure Boot is a sneaky tool developed by Microsoft to block the use and spread of Linux OS.

This perspective can be found all over Google, and the myth might even seem plausible if you explore your UEFI BIOS settings to enable Secure Boot. For instance, on my ASUS motherboard, enabling Secure Boot requires changing the OS type to "Windows OS." By default, it’s set to "Other OS," which essentially means Secure Boot is disabled.

)

Debian developers dealt with Microsoft signatures and Debian OS has its UEFI bootloader signed. This means you don’t need to deal with Microsoft to register anything or go through any registration/login ecc processes.

If you’re using the default Debian installer and an "official" Debian Linux kernel (from Debian package repos), Secure Boot shouldn’t pose any problems for booting. However, if your OS doesn’t support Secure Boot or its UEFI loader isn’t signed with Microsoft’s certificates—or if you’re running a custom kernel—this will obstacle the booting process until you have these custom components "signed". However, again, this doesn’t mean that Microsoft is anyhow involved in such signing process.

Secure Boot is about signatures in general, ensuring that only trusted and verified software can run during the boot process.

UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve. ()

In case of Debian, where do these drivers come from? Who adds them to the OS?

_Under Debian, the module can be installed from three different kind of sources:

• Upstream Linux kernel modules: Those are shipped in the linux-image-* kernel packages.


• Extra modules, that's aren't in the upstream Linux kernel. Those are usually built using dkms. The available modules can be listed by running apt rdepends dkms.


• Others, like third party, proprietary and other or binary blobs modules... You should not install such modules on your system except when you have no other choice. ().
  
  

Kernel modules in this category can be found in Debian repos, however maybe not always in main component of repo, but also in such components as non-free, contrib and non-free-firmware. (If you do not know how Debian ships its software and you do not know what are Debian repos and how to manage them you can check these articles ). In most cases, you can find drivers that can be build with DKMS in Debian repos.

Third-party binaries that build kernel modules for you may come on your horizon when some hardware pieces of your machine don’t work on your Debian setup, and drivers aren’t available in Debian’s package repositories. This often happens with Intel wireless adapters, Realtek WiFi chipsets, Bluetooth devices, input devices like keyboards or mice, USB storage devices, and so on.

However, when a hardware piece does not work/function well on your PC, it’s important to understand this difference: driver ≠ firmware! If firmware is missing on your OS, Debian usually informs you (Warning message in dmesg, journalctl, or when you update your kernel. If Debian informs you, that means that it did not manage to fetch it from any repo you have enabled for apt. You may need to add additional repositories (like bookworm-backports) or add components to the stable package repo (contrib, non-free, non-free-firmware). As a last resort, you can fetch a missing firmware directly from the of available firmware for Realtek WiFi chipsets). Firmware is tightly connected to the hardware device itself, essentially controlling the small controllers and metal chips within the hardware. The firmware is called upon by the driver when the device is in use.

So, if you have firmware but no driver for the device, you won’t be able to use it. Conversely, if there’s a working driver but it can’t find the correct firmware—or the firmware in use is faulty—the device won’t function properly.

For Secure Boot, you don’t need to sign firmware (.fw files), but kernel modules-drivers (.ko files) installed separately (that are not shipped with your OS from the start) do require signing. This is because firmware is invoked by kernel modules, and if those modules are untrusted or not loaded by UEFI, the firmware becomes irrelevant—no one calls or uses it.

With that said, let me conclude about third-party binaries that build kernel modules: use them only in cases of absolute necessity. Don’t resort to them to make some dubious Aliexpress USB “Super Mega Ultra Cool SSD 1,000,000 TB USB3.0” or a random WiFi/Bluetooth USB device work, do not pull something weird on your OS to play with LED colours of your keyboard following a first found guide. While it’s fine for experimental purposes, such as learning how hardware integrates with an OS, I strongly advise against using these solutions for long-term purposes. If something goes wrong, at best, you risk breaking your OS; at worst, you expose you breach security of your system.

Secure Boot Setup: your own signatures

So, now that I’ve hopefully explained the details about Secure Boot, I can proceed with setting it up. In the end, it all comes down to ensuring that your system’s kernel and kernel modules are signed—either with Microsoft signatures or manually using your own signature. A signature, in the context of Secure Boot, essentially is a key.

If you’re a software developer, you may already be familiar with the concept of keys. For example, authentication on GitHub uses ssh keys, or when you need to secure your app’s traffic over the HTTPS protocol, this involves generation of certificates and keys. Similarly, some applications with high-security access use this method of authentication, where access to certain resources is allowed only from specific devices. In such cases, you, the owner of device (PC), generate a key pair—public and private keys—and share the public key with the provider (app's owner). This key is then enrolled in their authentication system, allowing the server to use your shared public key to authenticate your private key when you connect. Your private key always remains only on your device (PC); it should never be shared and must be stored securely. But if you store it securely, there needs to be a system that manages your keys. Otherwise, when a request is sent, it’s not like the authentication mechanism of an app X will search through all the directories on your PC to find a matching private key. Instead, keys need to be created, registered, and enrolled in a structured way.

On Linux OSs, for Secure Boot all "signatures"-keys are managed by shim.

shim is a simple software package that is designed to work as a first-stage bootloader on UEFI systems.

A key part of the shim design is to allow users to control their own systems. The distro CA key is built in to the shim binary itself, but there is also an extra database of keys that can be managed by the user, the so-called Machine Owner Key (MOK for short).(.

Remember, if you’re using a custom kernel or a distro that doesn’t support Secure Boot by default, you won’t be able to boot once you enabled Secure Boot. Unfortunately, I can’t provide a guide for that case. I’m a Debian girl and I don’t use any other distro (except for Arch ho-ho). However, if you are in that situation, the idea is to do the steps I will describe below before enabling Secure Boot (not only that, however, you will have to deal also with GRUB). Once everything is signed for UEFI Secure Boot, you can enable it in BIOS*.

Disclaimer: For the next steps, I’m not reinventing the bicycle—I’m simply following the

If you haven't try to do something with key enrollment before, you will most probably see two enrolled keys: one is the Debian key, and the other is the Debian DKMS module signing key. However, even if this key appears in the list, it does not mean that it will automatically be used to sign any additional kernel modules you are about to build (or install). While there is functionality to export the enrolled MOKs for manipulation, using mokutil --export will export all enrolled keys in .der format, and a .der key is similar to .pub keys - they are "public" by nature. mokutil --export will never be able to extract for you private keys that were paired with .der keys. And without a private key, matching to any extracted .der key you will not be able to sign anything.

Therefore, you will need to generate a new MOK for manually signing additional kernel modules you are about to install. By the way, the keys currently enrolled in UEFI, if you did not enroll anything before, are not MOK keys—they are owned by Debian, not you.

In this article, I will be installing the nvidia-driver package from the Debian bookworm repository. NVIDIA drivers are kernel modules, and they require a signature to be loaded under Secure Boot. NVIDIA kernel modules are built using DKMS, if installed with nvidia-driver Debian package.

First, you have to create your first MOK - Machine Owner Key:

CODE Kopieren

$ su - #if you are logged

# mkdir -p /var/lib/shim-signed/mok/

# cd /var/lib/shim-signed/mok/

# openssl req -nodes -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -days 36500 -subj "/CN=My Name/"

# openssl x509 -inform der -in MOK.der -out MOK.pem

Then, you have to enroll this newly generated key, so it becomes acknowledged by shim and then by UEFI after reboot:

NB! store securely input password, you will need it later!

CODE Kopieren

# exit 

$ sudo mokutil --import /var/lib/shim-signed/mok/MOK.der # prompts for one-time password

sudo reboot

At the reboot, the device firmware should launch it's MOK manager and prompt you to review the new key and confirm it's enrollment (Press any key and then select "Enroll MOK" option, then "continue", then "yes", insert the password you have chosen when you enrolled the key with mokutil --import, then "Reboot"). After this, when you boot again, you can verify:

CODE Kopieren

$ sudo mokutil --list-enrolled

$ sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der

/var/lib/shim-signed/mok/MOK.der is already enrolled

Secure Boot Setup: Scenario 1 - Fresh install of NVIDIA drivers; configuring DKMS to automatically sign kernel modules.

If you have been following the . However, if you are here reading this article, it probably didn’t work for you.

I installed my Debian system using the netinstall .iso with minimal installation, including only the standard system utilities. I had the kernel and the default kernel modules installed. However, I did not have the kernel headers installed, nor did I have DKMS installed.

To check if your system has the dkms package installed, use the following command:

CODE Kopieren

sudo dpkg -l | grep dkms

If this package is not installed on your system of course you will not be able to "sign" it. When you run 'sudo apt install nvidia-driver', this package as a dependency will bring for you also dkms package. But after doing so, it will immediately proceed with building kernel modules without any signing (not what you want!).

However, if you have dkms package already installed, and if you list the content of directory /var/lib/dkms with ls and you see there keys, you can follow this

CODE Kopieren

sudo apt install dkms

#if you installed linux-image-* from bookworm-backports(kernel version >6.1.x)

#sudo apt install -t bookworm-backports dkms

sudo reboot

After rebooting, go to /etc/dkms and run ls—you should see the file framework.conf. Use cat to view its contents, and you will find the mok_signed_key and mok_certificate fields pointing to /var/lib/... However, if these directories are empty, it means there are no keys! In that case, you simply need to modify these lines, and point dkms to existing and enrolled MOK key pair.

CODE Kopieren

ls /etc/dkms

cat /etc/dkms/framework.conf

sudo vim /etc/dkms/framework.conf

#delete '#' in the beginning of the lines!

mok_signing_key="/var/lib/shim-signed/mok/MOK.priv" 

mok_certificate="/var/lib/shim-signed/mok/MOK.der"

Now, you can proceed with NVIDIA drivers installation:

CODE Kopieren

sudo apt install nvidia-driver

sudo reboot

CODE Kopieren

nvidia-smi

modinfo nvidia-current

VOILA!

Secure Boot Setup: Scenario 2 - NVIDIA drivers are already installed; using your MOK to sign installed kernel modules.

If you have already installed NVIDIA drivers and they worked perfectly before enabling Secure Boot but stopped working afterward, you have to repeat the steps mentioned above - generate MOK key-pair and enroll this MOK. Then, if you want that in future all kernel modules built with DKMS are automatically signed, you have to add path to your key pair into the DKMS configuration file. However, if you have installed NVIDIA drivers before, this DKMS config documentation will not have a reverse effect—kernel modules that have already been built and installed will not be signed. You have to sign those kernel modules manually, or reinstalled (rebuild) them. Additionally, if for some reason you plan to install kernel modules that will not be built with DKMS, they will also remain unsigned, and you will have to sign them manually.

For this example, I have installed NVIDIA drivers, but I did not sign anything. Therefore, after I boot, NVIDIA drivers are not available.

I see errors in the dmesg logs from the boot process: in lsmod, I do not see any loaded NVIDIA kernel module, and nvidia-smi shows an error:

So, these kernel modules I have to sign, to make them work under Secure Boot. This is the method

CODE Kopieren

#you have to use passphrase you used for enrollment of MOK

$ echo -n "Passphrase for the private key: "

$ read -s KBUILD_SIGN_PIN

$ export KBUILD_SIGN_PIN

#simple bash loop to sign all kernel modules found in the current directory

$ find -name \*.ko | while read i; do sudo --preserve-env=KBUILD_SIGN_PIN "$KBUILD_DIR"/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der "$i" || break; done

#or you can sign modules below the current directory one by one:

$ sudo --preserve-env=KBUILD_SIGN_PIN "$KBUILD_DIR"/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der nvidia-curernt.ko

...

$ sudo update-initramfs -k all -u

$ sudo reboot

Here is my result:

VOILA!

Summarizing (my personal advices):

🦄 Do not neglect this security mechanism; it is neither as scary nor as hard to configure as it may seem.

🦄 Do not disable Secure Boot carelessly.

🦄 Secure Boot protects you not only during the boot process but beyond.

🦄 Adapting your system to be compatible with Secure Boot is simply a matter of generating your Machine Owner Key (MOK), enrolling it (making it visible to UEFI), and then using it to sign your kernel modules or show the software that builds them for you (DKMS) where your enrolled keys are.

🦄 If you are a software developer and still find Secure Boot challenging or restrictive, I advise to reconsider it. Adapting your system for UEFI Secure Boot is an excellent exercise and an opportunity to deepen your understanding of keys, certificates, and key-based signatures—concepts you will undoubtedly encounter frequently in your developer career.

Vollständiger Original-Bericht

Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

↗ Original-Artikel auf dev.to lesen