Making UEFI Secure Boot Work With Open Platforms(linuxfoundation.org)
linuxfoundation.org
Making UEFI Secure Boot Work With Open Platforms
http://www.linuxfoundation.org/publications/making-uefi-secure-boot-work-with-open-platforms
35 comments
"I seriously do not understand why everybody has rolled over so hard on this issue."
It is the same reason that Linus Torvalds and plenty of other people have no problem with TiVO, or even see it as a success. A lot of people in the open source community do not subscribe to the free software philosophy. For a lot of people, as long as they can boot Linux by some means and continue to hack, there is no problem, even if Microsoft's signing key is required in that process.
Plenty of people also live in a state of denial about the bootloader restrictions. They do not believe that Microsoft would ever deny anyone the ability to turn the restrictions off, or that Microsoft would otherwise prevent us from running GNU/Linux. How anyone can trust Microsoft to not abuse its power is a mystery to me, but there are lots of people here on HN who seem to have such trust.
At this point, I do not think there is any debate about the FSF's stance on the open source movement:
https://www.gnu.org/philosophy/open-source-misses-the-point....
It is the same reason that Linus Torvalds and plenty of other people have no problem with TiVO, or even see it as a success. A lot of people in the open source community do not subscribe to the free software philosophy. For a lot of people, as long as they can boot Linux by some means and continue to hack, there is no problem, even if Microsoft's signing key is required in that process.
Plenty of people also live in a state of denial about the bootloader restrictions. They do not believe that Microsoft would ever deny anyone the ability to turn the restrictions off, or that Microsoft would otherwise prevent us from running GNU/Linux. How anyone can trust Microsoft to not abuse its power is a mystery to me, but there are lots of people here on HN who seem to have such trust.
At this point, I do not think there is any debate about the FSF's stance on the open source movement:
https://www.gnu.org/philosophy/open-source-misses-the-point....
I don't think the issue is the same as tivo, ie people have no problem getting locked out of their devices, I think the problem is that people are being deceived by the smokescreen that secure boot can (currently) be disabled (Through undefined, and very commonly broken/buggy mechanisms).
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?
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:
http://lwn.net/Articles/542327/
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.
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:
http://lwn.net/Articles/542327/
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"".
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"".
it is absolutely not misinformed FUD, fedora is not using the linux foundation bootloader.
Please read http://mjg59.dreamwidth.org/12368.html its the best document detailing the changes they are putting into place.
Please read http://mjg59.dreamwidth.org/12368.html its the best document detailing the changes they are putting into place.
> fedora is not using the linux foundation bootloader.
I'm very well aware of that. Here is another post from mjg59's blog that you might find enlightening:
http://mjg59.dreamwidth.org/18945.html
Especially the sections "Providing user control over trust" and "Providing user control over signature verification". A highlight for you:
Anything signed with the user's key will then be trusted.
edit: Here is another link detailing the shim bootloader mechanism:
http://mjg59.dreamwidth.org/20303.html
I'm very well aware of that. Here is another post from mjg59's blog that you might find enlightening:
http://mjg59.dreamwidth.org/18945.html
Especially the sections "Providing user control over trust" and "Providing user control over signature verification". A highlight for you:
Anything signed with the user's key will then be trusted.
edit: Here is another link detailing the shim bootloader mechanism:
http://mjg59.dreamwidth.org/20303.html
> why are they in a position to make it possible at all?
They are in that position anyways. Supporting or opposing SB does not change that.
They are in that position anyways. Supporting or opposing SB does not change that.
>like on surface systems.
Surface Pro ships with an unlockable bootloader. You can even remove Microsoft's own key and install your own so that Windows can't boot.
>They can either change a requirement to have the ability to disable it be optional, or make the inability to disable it mandatory, like on surface systems.
No, they cannot. The antitrust govt lawyers will be all over them if they want to try something like that.
>The problem with supporting secure boot is it legitimizes microsoft's role as the gatekeeper to computing
Microsoft doesn't mandate that their key must be the only one to ship by default. The fact that Linux community can't get together to make a signing infrastructure while the OEMs are willing to add keys is not Microsoft's fault.
>I seriously do not understand why everybody has rolled over so hard on this issue
Simple, because the user is in real control of their PC and can add/remove keys as they wish. And Secure Boot prevents the vast majority of non-techy users from getting undetectable bootkits installed on their machine.
Surface Pro ships with an unlockable bootloader. You can even remove Microsoft's own key and install your own so that Windows can't boot.
>They can either change a requirement to have the ability to disable it be optional, or make the inability to disable it mandatory, like on surface systems.
No, they cannot. The antitrust govt lawyers will be all over them if they want to try something like that.
>The problem with supporting secure boot is it legitimizes microsoft's role as the gatekeeper to computing
Microsoft doesn't mandate that their key must be the only one to ship by default. The fact that Linux community can't get together to make a signing infrastructure while the OEMs are willing to add keys is not Microsoft's fault.
>I seriously do not understand why everybody has rolled over so hard on this issue
Simple, because the user is in real control of their PC and can add/remove keys as they wish. And Secure Boot prevents the vast majority of non-techy users from getting undetectable bootkits installed on their machine.
>Surface Pro ships with an unlockable bootloader.
I was talking about surface systems, the arm ones with the locked boot loader, not surface pro, the similar naming only adds confusion to this issue.
>The antitrust govt lawyers will be all over them if they want to try something like that.
You totally ignored the point that now they can show antitrust lawyers all these linux distros and others that support secure boot! its not about maintaining a monopoly cough.
> Microsoft doesn't mandate that their key must be the only one to ship by default. The fact that Linux community can't get together to make a signing infrastructure while the OEMs are willing to add keys is not Microsoft's fault.
What about BSDs, what about haiku, what about the hacking project some guy wrote last week, should they all be held responsible "for not getting their act together" and getting OEMs to distribute their signing keys so Microsoft doesn't directly control their fate?
The point is that this is a very intentional barrier to entry, its exactly the same tactic Microsoft has been using for decades to shut out competitors, but its totally sincere this time, and only about protecting users? Sorry i don't buy it.
>Simple, because the user is in real control of their PC and can add/remove keys as they wish.
For now, and a requirement that was only added after Microsoft went ahead with requiring secure boot when people complained. They already distribute fully locked down systems, is it such a stretch to believe they will permit, or even mandate it in the future for x86?
Even if they never choose to lock down x86 systems entirely, why is this obvious conflict of interest being allowed to exist.
>Secure Boot prevents the vast majority of non-techy users from getting undetectable bootkits installed on their machine.
Anti-bootkit security does not imply UEFI Secure Boot where Microsoft controls the only key on every x86 PC of consequence.
I was talking about surface systems, the arm ones with the locked boot loader, not surface pro, the similar naming only adds confusion to this issue.
>The antitrust govt lawyers will be all over them if they want to try something like that.
You totally ignored the point that now they can show antitrust lawyers all these linux distros and others that support secure boot! its not about maintaining a monopoly cough.
> Microsoft doesn't mandate that their key must be the only one to ship by default. The fact that Linux community can't get together to make a signing infrastructure while the OEMs are willing to add keys is not Microsoft's fault.
What about BSDs, what about haiku, what about the hacking project some guy wrote last week, should they all be held responsible "for not getting their act together" and getting OEMs to distribute their signing keys so Microsoft doesn't directly control their fate?
The point is that this is a very intentional barrier to entry, its exactly the same tactic Microsoft has been using for decades to shut out competitors, but its totally sincere this time, and only about protecting users? Sorry i don't buy it.
>Simple, because the user is in real control of their PC and can add/remove keys as they wish.
For now, and a requirement that was only added after Microsoft went ahead with requiring secure boot when people complained. They already distribute fully locked down systems, is it such a stretch to believe they will permit, or even mandate it in the future for x86?
Even if they never choose to lock down x86 systems entirely, why is this obvious conflict of interest being allowed to exist.
>Secure Boot prevents the vast majority of non-techy users from getting undetectable bootkits installed on their machine.
Anti-bootkit security does not imply UEFI Secure Boot where Microsoft controls the only key on every x86 PC of consequence.
>Anti-bootkit security does not imply UEFI Secure Boot where Microsoft controls the only key on every x86 PC of consequence.
So then, Microsoft releases Windows 9. It's signed with Microsoft's key. You go out and buy a Windows 9 laptop. But wait, they didn't pre-enroll the Microsoft SecureBoot key, now you're screwed and you can't even boot your brand new computer.
That's the scenario if you don't pre-enroll the key. I'd love it if we could somehow guarantee they'll never change their mind and remove that requirement. In that absence of that, smarter solutions are needed- it's not as simple as people make it out to be.
So then, Microsoft releases Windows 9. It's signed with Microsoft's key. You go out and buy a Windows 9 laptop. But wait, they didn't pre-enroll the Microsoft SecureBoot key, now you're screwed and you can't even boot your brand new computer.
That's the scenario if you don't pre-enroll the key. I'd love it if we could somehow guarantee they'll never change their mind and remove that requirement. In that absence of that, smarter solutions are needed- it's not as simple as people make it out to be.
it could enroll on first boot, it could warn you if the boot sector/etc changes, it could do an almost infinite amount of things that do not require Microsoft to become the sole gatekeeper.
Microsoft could also make a legally binding gaurentee they would never change their minds about it, but you can be certain they wont.
There is a strong parallel to CableCard[1], when cable companies were allowed to bake their network PPV/etc authorization directly into their receivers, somehow it seemed that CableCard was never reliable for people with stuff like TIVOs, it would mysteriously fail dozens of times for them, each time requiring a visit from a cable company technician to replace the card, because thats of course, strictly nessisary. The FCC later mandated all devices must use CableCard for authorization, and these issues vanished.
I easily see a similar thing occurring for the ability to add your own keys.
[1]http://en.wikipedia.org/wiki/CableCARD
Microsoft could also make a legally binding gaurentee they would never change their minds about it, but you can be certain they wont.
There is a strong parallel to CableCard[1], when cable companies were allowed to bake their network PPV/etc authorization directly into their receivers, somehow it seemed that CableCard was never reliable for people with stuff like TIVOs, it would mysteriously fail dozens of times for them, each time requiring a visit from a cable company technician to replace the card, because thats of course, strictly nessisary. The FCC later mandated all devices must use CableCard for authorization, and these issues vanished.
I easily see a similar thing occurring for the ability to add your own keys.
[1]http://en.wikipedia.org/wiki/CableCARD
Enroll on first boot? Like literally the first time the laptop is powered on it siphons keys from the OS? That seems... counterintuitive.
Plus, it really doesn't solve the issue we're talking about. If it enrolls on boot then:
- system UEFI keys are modifiable (just like they are now)
- if you boot Windows 8 first, you're screwed... unless you can change the keys.... like you can now.
So even if they pre-enroll, you still have the exact same problem -- will the OEM/UEFI designer allow you to enroll keys or disable SecureBoot entirely?
Personally, I understand your worry 100% but I think it's needlessly paranoid. I simply don't see OEMs going for this, and even if they do, there will be models simply sold without the Windows 8 sticker or what not.
Plus, it really doesn't solve the issue we're talking about. If it enrolls on boot then:
- system UEFI keys are modifiable (just like they are now)
- if you boot Windows 8 first, you're screwed... unless you can change the keys.... like you can now.
So even if they pre-enroll, you still have the exact same problem -- will the OEM/UEFI designer allow you to enroll keys or disable SecureBoot entirely?
Personally, I understand your worry 100% but I think it's needlessly paranoid. I simply don't see OEMs going for this, and even if they do, there will be models simply sold without the Windows 8 sticker or what not.
the point of on first boot is that Microsoft will have to use the same mechanism as everyone else, and not be able to "prebake" keys, which subsequently (and quite coincidentally i'm sure) have bugs in their update procedure.
How is that any different. Even every single Linux user I know has bought a laptop and fired it up at least once before subverting the boot process to install Ubuntu right off the bat.
So, let's assume 99.999% of consumers will boot their laptop as soon as they get it. okay, we're still in the exact same boat we've been in. Unless I'm missing something...
>which subsequently (and quite coincidentally i'm sure) have bugs in their update procedure.
Given the multitude of bugs in various UEFI impls so far, I would say that this is a fairly legitimate concern. Especially as I'm assuming most people like you or I are likely to just disable SecureBoot altogether and never properly "test out" enrollment.
So, let's assume 99.999% of consumers will boot their laptop as soon as they get it. okay, we're still in the exact same boat we've been in. Unless I'm missing something...
>which subsequently (and quite coincidentally i'm sure) have bugs in their update procedure.
Given the multitude of bugs in various UEFI impls so far, I would say that this is a fairly legitimate concern. Especially as I'm assuming most people like you or I are likely to just disable SecureBoot altogether and never properly "test out" enrollment.
> Even every single Linux user I know has bought a laptop and fired it up at least once before subverting the boot process to install Ubuntu right off the bat.
Now imagine there's an option in the UEFI BIOS:
* Revert to trust-on-boot mode. WARNING: this may expose you to attacks by malware.
Now imagine there's an option in the UEFI BIOS:
* Revert to trust-on-boot mode. WARNING: this may expose you to attacks by malware.
Again, how is this any different than just letting the user enroll a key? Or using one signed by a supported key, or using one with a shimloader already ready to go?
I mean, I guess as a convenience mechanism, but then again, why not just disable it and be done with it. Maybe a chance that would make more sense to me would be to have an option:
* Extract SecureBoot keys from bootloader/kernel whatever
and be able to specify your own kernel or what not.
But then again, that's basically what you get via your own key enrollment ;)
I mean, I guess as a convenience mechanism, but then again, why not just disable it and be done with it. Maybe a chance that would make more sense to me would be to have an option:
* Extract SecureBoot keys from bootloader/kernel whatever
and be able to specify your own kernel or what not.
But then again, that's basically what you get via your own key enrollment ;)
[deleted]
>surface systems, the arm ones with the locked boot loader, not surface pro,
I guess you mean Surface RT. There is no "surface systems".
>For now, and a requirement that was only added after Microsoft went ahead with requiring secure boot when people complained. They already distribute fully locked down systems, is it such a stretch to believe they will permit, or even mandate it in the future for x86?
Sorry, but a thought crime is not a crime. That someone may or may not do something illegal in the future does not imply they should be prevented from doing something legal today.
>Anti-bootkit security does not imply UEFI Secure Boot where Microsoft controls the only key on every x86 PC of consequence.
Perhaps you have a better solution to prevent undetectable bootkits. My grandmom has a higher chance of getting a bad virus than wanting to install Haiku OS on her computer. I don't wish that her and hundreds of millions of other's PCs are left vulnerable to undetectable bootkits because a few people somewhere can't be bothered to uncheck a checkbox in order to install GNU/Hurd or because Microsoft may send thugs in the future to delete my Ubuntu install.
I guess you mean Surface RT. There is no "surface systems".
>For now, and a requirement that was only added after Microsoft went ahead with requiring secure boot when people complained. They already distribute fully locked down systems, is it such a stretch to believe they will permit, or even mandate it in the future for x86?
Sorry, but a thought crime is not a crime. That someone may or may not do something illegal in the future does not imply they should be prevented from doing something legal today.
>Anti-bootkit security does not imply UEFI Secure Boot where Microsoft controls the only key on every x86 PC of consequence.
Perhaps you have a better solution to prevent undetectable bootkits. My grandmom has a higher chance of getting a bad virus than wanting to install Haiku OS on her computer. I don't wish that her and hundreds of millions of other's PCs are left vulnerable to undetectable bootkits because a few people somewhere can't be bothered to uncheck a checkbox in order to install GNU/Hurd or because Microsoft may send thugs in the future to delete my Ubuntu install.
A murderer has murdered once, should we be wary about giving him the means and the ability to pull the trigger once again?
What is your point/alternative/suggestion? I mean, what do you want to see happen? I don't think anyone loves the influence Microsoft has on OEMs but what can be done from a market or legal standpoint? Or even as I mentioned in my other post, what can even be done from a technical standpoint to properly mitigate this further?
Alas, there's a long history of antitrust suits taking so long that the actions giving rise to them have had their intended effect and are no longer relevant.
Please review recoiledsnake's comment history. This discussion unfortunately has been had before.
Compliance with proprietary vendors' requirements? No thanks, I do not want Microsoft, Apple, Sony, or anyone else deciding how I use my computer. Shame that the Linux foundation cannot understand the most basic tenet of free software.
The coming civil war over general purpose computing
https://news.ycombinator.com/item?id=4436139
For this simple reason the Linux Foundation should stop wasting further energy for UEFI. As a Linux user from the very beginning (since 1992) I won't buy any UEFI device for Linux in general even if Linux would be 100% supported. I won't buy an expensive WinRT tablet just to put Linux on it.
When the Linux Foundation was founded I was happy to have a strong organization behind Linux. But today they make me really angry for supporting a system of someone who considered Linux, and the Open Source movement in general, as enemy. UEFI proves that they don't have changed their mind.
LF, please stop your unrealistic UEFI dreams, and please focus on the interests of the Linux community. I believe that most Linux users want functional hardware alternatives which will likely remain free from DRM restrictions. I would appreciate that even at the cost of incompatibility with the internet. In that case we would have to build our own new Internet, free from spam etc.
There are so many good devices like Raspberry and Beagleboard Black. They are powerful enough to be used as a desktop workstation when using a small and efficient Linux distro. Why not even enhance them with an e-ink display to make them a cheap alternative tablet pc that everyone can afford?
By the way, for the price of a single UEFI WinRT tablet we could build a whole server cluster of RPis or BBB.
When the Linux Foundation was founded I was happy to have a strong organization behind Linux. But today they make me really angry for supporting a system of someone who considered Linux, and the Open Source movement in general, as enemy. UEFI proves that they don't have changed their mind.
LF, please stop your unrealistic UEFI dreams, and please focus on the interests of the Linux community. I believe that most Linux users want functional hardware alternatives which will likely remain free from DRM restrictions. I would appreciate that even at the cost of incompatibility with the internet. In that case we would have to build our own new Internet, free from spam etc.
There are so many good devices like Raspberry and Beagleboard Black. They are powerful enough to be used as a desktop workstation when using a small and efficient Linux distro. Why not even enhance them with an e-ink display to make them a cheap alternative tablet pc that everyone can afford?
By the way, for the price of a single UEFI WinRT tablet we could build a whole server cluster of RPis or BBB.
[deleted]
You're fighting an uphill fucking battle, Linux Foundation and here's why: UEFI, the standard, is so loosey-goosey, with so many bits unspecified, that the only real test of whether the system is compliant that actually matters is "does it boot Windows". It's rather like the Web back in the day, when we had HTML and CSS and all of that but the only standard that people applied was "does it look nice and work in IE5". We've already seen one UEFI implementation from Samsung that can brick the machine when a non-Microsoft (or even sometimes a Microsoft) OS is installed on it; and one from Lenovo that actually searches the strings of the boot image looking for either "Windows" or "Red Hat Linux" and refuses to boot otherwise. Expect more cock-ups of this sort, whether due to malice or incompetence, to follow. This isn't about a hardware-verifiable boot process, it's about multiple vendor-specific boot processes, the only thing they can be guaranteed to have in common is their capability to boot into a Microsoft OS. Those of us disinclined to trust Microsoft will see this as a largely successful attempt to decommoditize the boot protocol, as per the Halloween Documents.
Theo de raadt already blasted Redhat and Ubuntu for instantly compromising and submitting to microsoft. Linux foundation non resistance makes no sense to me either since a lot of people who sit on the board are direct competitors to M$ you'd think they would want to save their companies from being at their mercy.
I'm waiting for when cloud o/s takes over that scans for pirate software/dissident behaviour or thought crime, and it becomes illegal to run your own operating system. There will be a Silk Road for computer hardware and guy's peddling BSD installs in dark alleys.
I'm waiting for when cloud o/s takes over that scans for pirate software/dissident behaviour or thought crime, and it becomes illegal to run your own operating system. There will be a Silk Road for computer hardware and guy's peddling BSD installs in dark alleys.
What should they have done? As I see it, they had three options with secure boot: find ways to work with it (as they have), try to get OEMs to disable secure boot or ship with a 'Linux key' as well, or ignore it and let users who want to install Linux deal with it.
Making users disable secure boot makes it that much harder and scarier to try Linux, so there would be even fewer users in the future. And I see no evidence that OEMs care enough about Linux to go out of their way to make life easier, even if someone did produce a 'Linux key' to sign all the major distributions. There are a precious few small OEMs that sell computers with Linux, but mostly to existing Linux users. If desktop Linux isn't going to fade into complete irrelevance, we're still crucially dependent on people experimenting with it on Dell/Lenovo/Acer Windows laptops.
Making users disable secure boot makes it that much harder and scarier to try Linux, so there would be even fewer users in the future. And I see no evidence that OEMs care enough about Linux to go out of their way to make life easier, even if someone did produce a 'Linux key' to sign all the major distributions. There are a precious few small OEMs that sell computers with Linux, but mostly to existing Linux users. If desktop Linux isn't going to fade into complete irrelevance, we're still crucially dependent on people experimenting with it on Dell/Lenovo/Acer Windows laptops.
Link is mentioned in this debate: https://news.ycombinator.com/item?id=5658184
No, this is not what I want, the secure boot is MS's evil plan and I want to get rid of the whole shit.
This PDF carries a date of October 2011.
And as most people hopefully know, despite the random FUD here and on reddit, SecureBoot is simply not an issue for x86 computers. The only issues so far with Linux + SecureBoot were actually due to OEM bugs in the UEFI implementation. Ubuntu and Fedora both handle SecureBoot seamlessly. Other distros will follow, especially with the Linux Foundation finally releasing their shim loader late last year.
They can either change a requirement to have the ability to disable it be optional, or make the inability to disable it mandatory, like on surface systems.
Thats the real issue. In very real way, Microsoft now hold the keys to the future of the x86 PC archecture, and I question why people are so ready to trust them considering their history.
The problem with supporting secure boot is it legitimizes microsoft's role as the gatekeeper to computing. Now with a straight face they can say to regulatory bodies "look at how many free and open source operating systems support secure boot, there is no monopolization here". They are then free to turn the screws, and make disabling secure boot impossible.
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". This is part of the agreement they signed to get keys signed by Microsoft. These signed keys can also be revoked by mictosoft at any time.[1]
I seriously do not understand why everybody has rolled over so hard on this issue.
[1] http://mjg59.dreamwidth.org/12368.html