zlacker

If secure boot is enabled on the motherboard, Fedora can be installed and used without going into the motherboard firmware and turning it off, but that is different from secure boot's providing to the Fedora install the kind of security assurances that secure boot provides to the other mainstream operating systems (Windows, MacOS, iOS, Android and ChromeOS).

For instance, initrd is not verified: >>36717975

>The page you link goes into custom secure boot keys, which are usually unnecessary.

You might be right about that.

>>holler+(OP)
It's true initrd is not verified; the system boots but the security secure boot is supposed to provide is not available by default. I don't think many Fedora users care, but that can be an issue.

To use secure boot without calls to mokutil and friends, Unified Kernel Images are introduced in Fedora 38. These images contain everything (kernel, initrd, and so on) in one, published package. If https://bugzilla.redhat.com/show_bug.cgi?id=2159490 is to be believed, UKIs are live already in Fedora 38.

I can only find pregenerated UKIs for virtual machines in the Fedora repositories and I can't tell if they're properly signed or not, but support is being extended and this problem is being solved.

As for providing security: Linux really needs an easy, user-friendly GUI application for setting up proper secure boot. Of course at least one step is out of the control of Linux developers (configuring the firmware to load new keys) but right now "I want to load my system keys (and also the keys for my Linux dual boot)" is awful on any Linux distro. Every guide presents scripts to call scripts to call automated tools but none of them seem to make the process any easier or friendlier.

>>jeroen+V5
Unified Kernel Images sounds like a useful improvement. I imagine that when combined with whole-disk encryption it provides useful protection against evil-maid attacks, but I haven't been able to find any signs that there is any Linux install in existence anywhere--except for Android and ChromeOS--where the boot process can detect an alteration to a file in /usr/ (e.g., the system's C library) and refuse to boot or at least warn the user. Unlike an evil maid, malware that has succeeded in its goal of running in a privileged process can alter any file in the unencrypted root filesystem.

In my search I focused on the "immutable" distros like Silverblue because it seems to me that the immutability would make the implementation easier.

In contrast, all the other mainstream OSes can detect an alteration in something like the C library during boot.