Verified boot describes the process of cryptographically verifying all executable code and data that is part of the booted system.
Android does this for a long time, Fedora (and Windows) only support “secure boot” which afaik just measures the kernel, which is cryptographically signed.
The HEADS firmware implements this for desktop operating systems.
It measures firmware and boot files, and signs them with a GPG key that can be stored on a GPG key/card, like a Nitrokey.
In this video, coreboot developers discuss usability issues with HEADS, and how it could be improved.
One of them is, that you need to accept the unknown state after an OS update as “fine”, and resign the boot files on the next boot.
With an OS update, especially on atomic-desktops the boot files always change, so you need to do this so often that it kinda becomes irrelevant to have verified boot.
An attacker would just need to wait for an update, and through “security fatigue” users will boot anything, as they expect changes in the boot files.
Alternatively, if Fedora could hash and sign all the boot files with a key, HEADS (or other verified boot implementations, for example in Tianocore or proprietaty UEFI) could just take that.
Boot would be quicker, and this huge security hole would be closed, as the boot files are cryptographically signed, instead of trusting a random “probably fine” state.
It would be great to implement this.
What this means is, that the build system would just hash the files and sign them, maybe all of them at once (is that possible without tarring them?).
Then the signature would just be another file, placed in the boot root directory, maybe in a subdirectory.
Users would need a way to securely obtain the public key that is used to sign these files.
It could also just be shipped at the same location, with the danger that it could be manipulated later on.
At first, this would not be used. And it will not be used until HEADS implements a method to use these signatures, or other firmwares even start to care about verified boot.
But it would allow this and greatly improve desktop Linux security, compared to Android (which is worlds ahead here, measured boot, secure element, locked bootloader)
Important: this is essential to make nonstable OS-es like Fedora reasonably work with this concept.
HEADS is often used with QubesOS, where only the Xen hypervisor is booted, which I assume doesnt have updates that often.
I use HEADS+ kinoite on a machine and it has the mentioned issue.