Using Secure Boot for the powers of good
summary
Secure Boot can be a user-controlled root of trust rather than a vendor lock‑in: produce an x509 key with openssl, sign a bootloader with sbsign, enroll the public key in firmware (setup mode) and the machine boots only images signed by that key. Practical tools and deployments exist: Fedora ships a Microsoft‑signed shim and a Red Hat‑signed bootloader so replacing MS keys yields a working user‑rooted flow; caveats include kernel kexec and firmware vendor signing (CPU microcode and NV‑RAM write paths) that still block a fully open chain.
AI-written summary · about
chapters (12)
- 0:00Secure Boot introduction
- 0:53What Secure Boot is
- 3:23Secure Boot vs Restricted Boot
- 7:16Threats to the boot process
- 10:51Restricted Boot harms freedom
- 15:25Secure Boot empowers users
- 23:16Secure Boot in data centers
- 24:22Implementing Secure Boot
- 29:02Building trusted systems
- 34:21Firmware alternatives limits
- 38:54Free-software-only devices
- 39:58Summary and call for control
related talks
30mEnabling UEFI Secure Boot Across Modern Build Systems
39mSecuring firmware: Secure and Trusted boot in OpenBMC
42mPractical Application of Verified Boot
49mSecure Boot from A to Z
42mBecoming a tyrant: Implementing secure boot in embedded devices
33mOpenPOWER: Host OS (Linux Kernel) Secure Boot Key Management
33mThe Various Shades of Supply Chain: SBOM, N-Days and Zero Trust
27mSecure Boot auto enrollment