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