Skip to content
leosmith.wtf·

🔐Secure Boot Signing Chain Explained: Shim, MOK, and Custom Keys for Linux

Your custom Linux kernel won't boot without this

TL;DR

Secure Boot on Linux runs on a chain: BIOS trusts Microsoft's UEFI CA 2011, Microsoft signs the shim, and the shim trusts your own keys. Build a custom kernel or GRUB and you need to enroll your key through MOK or the boot fails.

Secure Boot is only as good as the chain behind it, and Linux's chain runs through Microsoft. Your BIOS ships with Microsoft's UEFI CA 2011 key, Microsoft signs third-party shims, and the shim borrows that trust to boot GRUB and your kernel. Break any link and the machine stops. If you build your own kernel or ISO, this is your problem. The shim-signed package signs the shim, but GRUB and the kernel still need your own signatures. Sign GRUB with an unrecognized key and the shim drops you into MOK, the Master Of Keys enrollment screen, where you pick the key that matches your GRUB and Linux signatures. The mechanics are concrete. Generate keys with openssl req -newkey rsa:4096, sign the kernel with sbsign --key, and rename the EFI binary to grubx64.efi before signing it. Check shim signing with sbverify --list. Live USBs can't sign the kernel unless you build it manually, and Arch's archiso hook at airootfs/etc/pacman.d/hooks/zzzz98-mok-signing.hook handles signing at build time.

Key Points

1

Microsoft Corporation UEFI CA 2011 is the root key baked into most BIOSes, and it signs third-party shims so Linux distributions can boot under Secure Boot.

Keep reading — it's free

Enter your email to keep reading — plus the best of AI & tech, daily. Free, forever.

Also get
or

Already a member? Sign in

secure-bootlinuxuefishimmok

Comments

Subscribe to join the conversation...

Be the first to comment