* 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
--
Red Hat GmbH,
https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill