# Concepts ## Secure Boot The UEFI refuses to load binaries that aren't in a trusted key store. ## Trusted Boot Is actually what we usually mean when we talk about secure boot. All blobs that talk to the hardware need to be signed and, when loaded, this signature is verified against a key store in the firmware. Unsigned or unknown or revoked signatures end in boot failure. This is enforced by each consecutive level of the boot from firmware to kernel. Each level can also add extra keys which is kind of what shim does. The key store can be inspected with `mokutil --db` and the like in user space. ## Shim Shim acts as first level boot entity directly after the firmware. It creates magic extra tech that makes secure boot more palatable for Linux by letting vendors, or the user (interactively), add extra keys. The kernel and stuff is then signed using one of these keys rather than by Microsoft directly. The idea is that the shim build iterates rarely while the kernel behind it may update daily. Shim gets complemented by mokutil in user space which offers a way to inspect what is inside the shim `mokutil --list-enrolled` for example. ## SBAT Tightly relates to shim. It serves as a way to identify where blobs came from, what "version" they have, and who else meddled with them. This acts as a secondary revocation system that is more flexible than the firmware-level DBX (the firmware revocation) store. ``` sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,2,Free Software Foundation,grub,2.04,https://www.gnu.org/software/grub/ grub.fedora,2,The Fedora Project,grub2,2.04-33.fc33,https://src.fedoraproject.org/rpms/grub2 ``` This is an example SBAT as it would appear in the fedora build of grub with the generation 2 (mind that this is basically revocation version, not real version). When a vulnerability is found in grub the generation gets bumped to grub,3 and once rolled out every grub that doesn't have the correct SBAT value gets refused. Similarly, if grub.fedora,2 gets revoked only grub.fedora is affected while e.g. grub.debian,2 would not be. Consequently .sbat values should be set on all EFI binaries so they can be revoked through SBAT rather than DBX. ## Measured Boot Is a side effect of Secure and Trusted Boot. Artifacts that get loaded during boot are also hashed (aka measured) into the TPM, creating a hash identifying the boot line up. This isn't used much in Linux yet but technically allows organizations to remotely attest if a boot was indeed fully trusted (i.e. produced the expected hash). Alongside the TPM measurements it also creates a log that can be read from user space with `tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements` which would aid in attestation (you can figure out which step produced unexpected results and then have a policy around whether that step is critical to attestation or not). # Docs ## Microsoft - https://techcommunity.microsoft.com/blog/hardware-dev-center/signing-with-the-new-2023-microsoft-uefi-certificates-what-submitters-need-to-kn/4455787 - Requirements https://techcommunity.microsoft.com/blog/hardware-dev-center/updated-microsoft-uefi-signing-requirements/1062916 - https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot - https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process - https://techcommunity.microsoft.com/blog/windows-hardware-certification/pre-submission-testing-for-uefi-submissions/364829 - How to submit (follows shim review) https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/file-signing-manage ## Shim - https://github.com/rhboot/shim-review/blob/main/README.md - https://github.com/rhboot/shim-review/blob/main/docs/submitting.md ## Misc - https://wiki.ubuntu.com/UEFI/SecureBoot - https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot - (keep boot loader small?) https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069 - https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html ## SBAT - https://mjg59.dreamwidth.org/70348.html - https://github.com/rhboot/shim/blob/main/SBAT.md - https://lwn.net/Articles/938422/ # Technical Stuff - we need an (ideally EV certificate so UEFI signing is faster, supposedly, though it's unclear -- everyone seems to use CA certs instead in shim?) signing key pair - needs to be kept safe - shard (split) it across multiple people? - needs to be hardware based (yubikey? tpm?) - we need a notary service https://invent.kde.org/sysadmin/ci-notary-service - confirm notary operating environment meets https://en.wikipedia.org/wiki/FIPS_140-2 Level 2 - maybe actually have a manual signing step? - we need a shim build - needs to have a reproducible build so it needs building against an arch snapshot or something similar - needs to be reproducible in a docker setup - we need to add sbat to: - fwupd - fwupdate - UKI - systemd-boot - systemd-stub - shim - need to make sure all kernel modules are signed - we need our own signing certificate that we can use to sign systemd-boot onwards - shim gets signed by Microsoft - firmware -> shim (MS) -> systemd-boot (us) -> kernel (us) -> modules (us) - getting the paths right is a bit fiddly and we can't rely on `bootctl install` it seems because it doesn't provide sufficient control over what goes where. custom tooling probably needed to put everything (shim, mm, systemd-boot) into `BOOT/` and `kde/` dir layouts ``` /boot/EFI/BOOT/ ├── BOOTX64.EFI ├── mmx64.efi └── systemd-bootx64.efi ``` ``` /boot/EFI/kde ├── mmx64.efi ├── shimx64.efi └── systemd-bootx64.efi ```