A way your distro to support Secure Boot

Transcript

1. A way your distro to support Secure Boot Haruki TSURUMOTO OpenSUSE.Asia Summit 2024 Cross-distro track 2024/11/03
2. 2 Disclaimer • Based on my personal experience • I have not authority on shim review process • x86_64
3. 3 Introduction • My name is Haruki TSURUMOTO • Working at Cybertrust Japan Co, Ltd. (formerly Miracle Linux Corporation) – I have experience passed one submission of boot-loader(shim) for RHEL-derivative distro
4. 4 What is Secure Boot? • Security feature in UEFI – Default in modern computing environment – Ensure boot-loader is not modified by attacker • Guard boot process from malware • On typical GNU/Linux systems – Related software: shim, GRUB(GRUB2), and Linux kernel
5. 5 What is shim? • We know GRUB and kernel, but shim is not enough. • shim is first-stage boot-loader • Verify second boot-loader(normally GRUB2) is signed by certain entity, and take over to it. • If boot-loader is not-signed or modified, shim will block boot process.
6. 6 Tools for Secure Boot • pesign/sbsign • Yubikey(Recommend) – Hardware Security Module – Signing in HSM is secure • efibootmgr • mokutil/certutil Most tools are available from rpm/deb repo ☺ If you build custom kernel for Secure Boot enabled env, these tools are helpful.
7. 7 Issues for home-brewer • When you build own kernel or boot- loader for your needs, there are two options. – Disable Secure Boot from UEFI settings – Register your key to MOK(Machine owner key) • Either options are only usable for power user – Distribution should take another way
8. 8 First-stage boot-loader sign • GRUB2 and kernel are signed by distributor’s private key – shim must be signed by vendor’s key. • How we get sign each shim for UEFI?
9. 9 First-stage boot-loader sign • GRUB2 and kernel are signed by distributor’s private key – shim must be signed by vendor’s key. • How we get sign each shim for UEFI? – One simple answer: Request sign to Microsoft via Azure • Because only Microsoft’ CA is commonly used CA • Other way: Request each hardware vendor(e.g. Platform key), but this is not practical.
10. 10 Why creating, forking, derivative a own new distribution is last resort • Most Problem is how to get sign from Microsoft. • Supporting Secure Boot needs work – Modify, Improve, Rebuild components are makes you must pass own shim review process • So I don’t recommend forking thoughtlessly… – Investigate already exist distributions – Indeed, Many RHEL-derivative, Ubuntu-derivative, Debian-derivative are there, it overflows.
11. 11 Passing review process is difficult • Passing rhboot/shim-review is require before request to MS – Forms(Vulnerabilities are fixed?, Private key storing) – Questionings with reviewer – shim binary is reproducible (build in container) – Participate to other vendor’s shim review • Lack of review resource – I will explain
12. 12 Lack of review resource • Review queue is always overflow – Community has not many reviewers • Specially, authorized member(~4 members) – I think they are volunteer staff from Red Hat, Canonical and Debian – Not quickly response • When someone creating a new fork distribution, this situation getting worse.
13. 13 Conclusion • Custom-kernel for yourself is fun, but rebuild for public use(=support Secure Boot) is difficult. • Surprisingly, it’s difficult for Microsoft too, they submitting review for himself distro(e.g. Azure Linux) – 5 months passed, but accept label is not added. – Theoretically, they can skip community accept. • If you are special case, let’s challenge shim-review process.