5 ms·

Here is the major problem with UEFI Secure Boot. Microsoft only changed the reqirement that secure boot must be possible to disable after there was a public out

by throwaway2048 14y ago

Here is the major problem with UEFI Secure Boot. Microsoft only changed the reqirement that secure boot must be possible to disable after there was a public outcry, and are free to change it again any time. 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 http://mjg59.dreamwidth.org/12368.html

betterunix 14y ago
"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.html https://www.gnu.org/philosophy/open-source-misses-the-point....
- throwaway2048 14y ago
  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).
recoiledsnake 14y ago
>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.
- throwaway2048 14y ago
  >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.
zokier 14y ago
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?
- throwaway2048 14y ago
  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/ 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.
  - zokier 14y ago
    > 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"".

betterunix 14y ago

"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.html https://www.gnu.org/philosophy/open-source-misses-the-point....

throwaway2048 14y ago
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).

recoiledsnake 14y ago

>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.

throwaway2048 14y ago
>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.

zokier 14y ago

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?

throwaway2048 14y ago
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/ 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.
- zokier 14y ago
  > 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"".