Skip to content

Instantly share code, notes, and snippets.

@marcsello

marcsello/debian-secureboot-2026.md

Last active July 14, 2026 07:46
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save marcsello/b210da018b8cac3f9ee91c345bc678da to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save marcsello/b210da018b8cac3f9ee91c345bc678da to your computer and use it in GitHub Desktop.
Download ZIP
My notes on setting up secure boot on Debian in 2026
Raw
debian-secureboot-2026.md

Debian half-manual Secure Boot setup in 2026

My notes on setting up secure boot on Debian in 2026. These are not meant to be a coherent write-up, just a bunch of notes I learned during my 5 days spend setting up secure boot

Make sure esp is mounted while installing stuff

My mountpoint is for ESP is /boot/efi most tools default to this path, and they also check if the partition is mounted.

I like to set noauto here sometimes, depending on what am I trying to achieve. This results in /boot/efi not being mounted.

Most package install scripts will fail silently here if it's not mounted, causing a headache.

MOK is not actually a firmware thing

MOK keys are just stored in the nvram, but uefi does not seem to do anything with it by itself. All MOK infrastructure seems to be implemented in shim-signed instead.

MOK Manager is one of these things. Some writeups refer to it as begin "invoked by the firmware" or write about it being a firmware thing, but that's wrong. MOK is implemented in shim-signed.

So to launch MOM Manager, shim has to be launched first! Also to pass along MOK keys and mok state to systemd-bootd, and thus the OS, the system HAS TO BE launched by shim.

UKI is cool

Kernel is signed by debian. That's cool. But it wouldn't validate our initramfs... which is a security gap. Anyone could put some onion-spicy in the initramfs and it would go unnoticed. Therefore we must sign inintramfs, and all the other stuff loaded at booting, like microcode.

UKI bundles all this up to a single EFI PE binary which can be signed by MOK (or the complicated thing described below) so initramfs will be validated as well.

Desired boot flow

The following flow just works:

firmware -> shim-signed -> systemd-bootd -> Debian UKI

That's because the firmware with it's default Microsoft keys will be able to validate shim-signed. Which embeds Debian's keys, which is used to sign systemd-bootd which loads our OS. systemd-bootd does validate our os, but if it uses MOK, it requires shim to pass the MOK stuff to it.

Seems like they forgot to mention this to systemd-bootd as for some reason it always attempts to override to boot entries and the boot order, so it gets loaded instead for shim, and it fails to do so... idk the reason for that.

Shim might not be needed

It seems like there are two ways to veify stuff that you are loading

  1. Some complicated magic, with a lot of keys and stuff (
  2. MOK

The first one is used by UEFI to verify what it loads. By default those are the Microsoft keys, that also valid for shim-signed. On some systems (Lenovo ThinkPads for example) these can be replaced by any other key, and use that to sign your bootloader/kernel. This way shim is not actually needed, because UEFI will trust the bootloader. But this is tedious and not that greatly documented (altrough Arch Wiki done it).

MOK is easier to setup, it's just a simple RSA keypair that can be generated by openssl, but it requires shim to be present in the boot chain.

Microsoft keys and the illusion of security

If you trust Microsoft keys, anyone can walk up to your computer and load Microsoft signed stuff on it, like shim, with their own config, grub, and an official debian image. And even replace what's in there with signed stuff.

To avoid this, Microsoft keys must be replaced with the complicated stuff. So only stuff that you specifically signed can be loaded on the machine.

At this point, setting a bios password would also be a must have, otherwise anyone could disable secure boot, reset Microsoft's keys, etc. Must be cautious with this, because forgetting the supervisor possword would also mean locking yourself out permanently, and potentially soft-bricking the device (some laptops have very involved way of resetting the password, like sending it in to the manufacturer)

Useful writings, topics, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment