I find the argument "MS can change the requirement to make SB locked down" very fallacious. Sure, they could do that. But they could also do that even if we didn't have this unlocked SB thing that we do. In other words, Microsofts ability to require locked down SB is unaffected by current state of SB requirements. So there is no reason for outrage against MS about the current situation with SB on x86 platforms, because even if we didn't have SB now MS would still have the ability to make locked down SB mandatory.
If there is someplace that would need outrage, it would be the utter crap that gets shipped as the firmware, first as bios and now uefi seems to follow the same path. And the blame for that lies squarely at the hands of HW manufacturers.
>Not to mention distributions like fedora are making massive changes to restrict access to users of their os when it is booted via secure boot, to prevent windows from being "compromised".
Would you mind expanding on this, what are these "massive changes" you speak of?
Why is it fallacious to question the motives of a company that has used tactics like these many time previously? Its simply boiling the frog, overcome the initial opposition by offering a workaround, then when many linux distros support secureboot (solely via their authorization channels) they can begin applying more restrictions. This is the first item in the Microsoft playbook for stifling competition.
Even if you don't believe that is what they are going to do, why are they in a position to make it possible at all?
As for distro users being restricted, read the referenced blog post, stuff like no non-fedora signed kernel modules, no custom kernels.
Not to mention the cluster fuck with CAP_COMPROMISE_KERNEL currently brewing in kernel land:
The real problem being, that now kernel functionality is beholden on wither it can comprise an existing windows boot somehow when booting with secure boot.
> As for distro users being restricted, read the referenced blog post, stuff like no non-fedora signed kernel modules, no custom kernels
That's just misinformed FUD. The shim bootloader allows user to enroll her own keys, which allows her to boot to whatever code she wants. So installing your custom kernel might require extra step or two, but it's certainly not being entirely restricted from users.
From my point of view the signing requirements are added in the spirit of "if we are going to support SB, lets at least do something useful with it", and not as you put it "to prevent windows from being "compromised"".
If there is someplace that would need outrage, it would be the utter crap that gets shipped as the firmware, first as bios and now uefi seems to follow the same path. And the blame for that lies squarely at the hands of HW manufacturers.
>Not to mention distributions like fedora are making massive changes to restrict access to users of their os when it is booted via secure boot, to prevent windows from being "compromised".
Would you mind expanding on this, what are these "massive changes" you speak of?