Chris Murphy wrote:

If you want to take the risk of acquiring a rootkit that can permanently take control of your firmware, that is up to you. It should not be a distribution recommendation to subject users to such bad advice.

And the "good advice" would be to accept that your computer will only run operating systems approved by Microsoft and to accept a security model that prevents basic functionality such as hibernation, third-party kernel modules, etc.?

And for the record, my computer's UEFI firmware is so old that "Secure Boot" cannot even be enabled at all, even if I wanted to.

Kevin Kofler

Neal Gompa wrote:

Don't blame Microsoft for our failings. The fact that we can't do hibernation or offer an easy path for third-party kernel modules to function in a Secure Boot environment is *entirely* our fault. After shim->grub2, Microsoft's trust ends and ours begins. We use *our* certificate from GRUB onward.

Sorry, there is a misunderstanding there. I did not intend to blame Microsoft for the restrictions within the kernel Linux imposed by the security model. There are 2 separate issues here:

1. Any operating system (in practice, the initial bootloader, shim in our case, but that is shipped by the operating system) must be signed by Microsoft to boot at all. AND 2. The security model prevents basic Linux kernel functionality.

Both are ultimately failures of the UEFI spec and not of Microsoft. Microsoft is not a party to issue 2 at all.

The fact that hibernation is broken in Secure Boot is entirely the fault of the engineers that were in charge of developing the Fedora kernel and bootloader security mechanism, because they created the patch set that made it functionally impossible to make it work. That is, it's the LOCKDOWN feature layered on Secure Boot, not Secure Boot itself.

The thing is, the engineers claim that this LOCKDOWN "feature" is necessary to comply with the Secure Boot spec. I know some other distributions have a different interpretation, which makes this security entirely moot, because if the non-locked-down kernels break the security model, it is enough to have one distribution offering a signature path to such a kernel and the security model is already broken. But despite that, Red Hat does not want to take the risk of being held responsible for breaking the security model.

It's obvious Secure Boot itself is no impediment to hibernation, since both Windows and macOS (both users of Secure Boot) can do hibernation just fine.

I don't know what they do differently. All I know is that it is not allowed by the Fedora kernel under Secure Boot restrictions.

There are also other, more subtle restrictions, such as banning even root from accessing kernel memory.

Meh. That means your computer was made before Microsoft started having vendors require UEFI firmware to include their keys for Windows certification (which was in 2006/2007). I'm surprised it still works. More power to you, I guess?

It is actually an ASUS P8Z68-V motherboard, introduced in 2011. It is labeled as "Windows 7 ready". According to: https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_b... the Secure Boot requirement was introduced with the Windows 8 certification in 2011, which my motherboard predates.

Kevin Kofler

* Florian Weimer:

• Neal Gompa:

...

None of this had to be this way. It is so by our own inaction, not by the action of Microsoft.

I agree. No one but Microsoft stepped up and was willing to control the key material.

I still wish we went the way of documenting how to disable Secure Boot in commonly used firmware implementations. Secure Boot does not offer any benefit to a platform designed to be as malleable as Fedora is. I tried to start that documentation, but I got the distinct impression it was unwanted.

Instead run-time disabling of Secure Boot support without reboot comes and goes, particularly in downstream kernels. Kernel modules are such an important diagnostic tool, and not everyone plans ahead and disables Secure Boot in case they need to load kernel modules later.

(“run-time disabling of kernel lockdown“ is more accurate—but of course if there's an off switch for this feature, lockdown isn't very effective in the first place.)

...

...

And for the record, my computer's UEFI firmware is so old that "Secure Boot" cannot even be enabled at all, even if I wanted to.

Meh. That means your computer was made before Microsoft started having vendors require UEFI firmware to include their keys for Windows certification (which was in 2006/2007). I'm surprised it still works. More power to you, I guess?

Last time I checked this, the Microsoft keys required for Windows certification were not those used to sign third-party binaries like the Fedora shim (the “Microsoft Corporation Third Party Marketplace Root”). You could see the difference in Hyper-V configurations, where the default Secure Boot configuration cannot boot Fedora.

Thanks, Florian

Chris Murphy wrote:

This is such an old argument. I know you've been around in Fedora long enough to actually understand this stuff if you really wanted to at least not spread misinformation.

I do not see how I am spreading misinformation. I think you are misunderstanding me. I do not intend to blame Microsoft for all the issues with the Secure Boot spec, they are only the monopoly for the signature of the initial bootloader. See my reply to Neal Gompa.

Microsoft does not approve or disapprove of operating systems. They have an EFI signing program for developers. They are signing just our shim bootloader. Fedora signs the other things in the boot chain.

Where have I claimed anything else? The fact is still that the requirement for Microsoft to sign the initial bootloader gives them veto power over any operating system running on users' computers.

And that is the one and only flaw (out of several) in the spec in which Microsoft is involved. The remaining issues are inherent to the spec itself.

Anyone can enroll their own signing keys with the firmware, sign the bootloader, kernel and kernel modules, including 3rd party. You can even mix and match signed binaries. And those binaries will comply with a Secure Boot enabled system just fine, without having Microsoft signatures on anything. Yes that's tedious and it would be better if it were easier than it is right now.

While I appreciate that the shim developers introduced this workaround (IIRC, it actually comes from openSUSE developers, not Fedora or Red Hat developers), this is absolutely impractical compared to just disabling the restrictions altogether.

Windows supports hibernation, with UEFI Secure Boot enabled. We don't because Linux hibernation images are inherently insecure by design and thus are a loophole for thwarting the Secure Boot regime.

I do not want my computer to impose a regime on me. I want to decide what I run on my own computer, I do not want my computer to decide for me. Say no to Treacherous Computing!

Therefore a kernel lockdown policy is applied to disallow hibernation if Secure Boot is enabled. It can be fixed, but the resources to finish that work have not yet materialized.

Even that will still not fix the other restrictions inherently caused by this security regime.

Literally none of this is Microsoft's fault.

I have never claimed otherwise.

And rootkits predate UEFI.

Yet, we were running just fine all these times without something like "Secure Boot".

Kevin Kofler