The Red Hat blogger mentions an unnamed OEM that he claims won't have this option. However, instead of naming that OEM so that we can shame and/or avoid them, he instead wants to shift the blame on to Microsoft. (And then in the same breath, will call Windows insecure coz of the rootkits that load before the anti-malware can).
The relevant quote is: "Garrett said that Windows 8 certification requires that hardware ship with UEFI secure boot enabled. A feature allowing secure boot to be disabled – necessary to run Linux and FreeBSD on certified systems – is not required for certification."
And further: '"We've already been informed by hardware vendors that some hardware will not have this option," Garrett writes in a flow-up blog post to his original critique of the technology.'
The ability to disable it is in the spec, but it's not required by the spec. Equally, the ability to override security decisions on a case by case basis is in the spec, but the Microsoft certification requirements forbid it.
Huh, what? The ability of disable secure boot IS in the spec, and it is included in the Samsung tablets that Microsoft got Samsung to make for their developers. How was it implemented if it's not in the spec.
Sorry, but I tend to agree. Microsoft could produce a secure (and optional) signed bootloader that could chain load Grub, but they won't. They could require an option for consumer-targeted devices to have the Microsoft sticker, but they won't. There is almost no downside to requiring this, except for the fact that it can only serve to hurt their business. I'm not sure I blame them from a business perspective, but it feels awful par-for-the-course-Microsofty.
(I don't mean to be rude or presumptuous, but your other comment seems to indicate that you're not fully understanding the technical workings or implications of a non-disable-able UEFI secure boot).
>There is almost no downside to requiring this, except for the fact that it can only serve to hurt their business. I'm not sure I blame them from a business perspective, but it feels awful par-for-the-course-Microsofty.
I think your energy will be better served railing against the alleged OEMs that won't include the option, instead of against MS. They're trying to clean up rootkits that load before antivirus to make their OS more secure.
>(I don't mean to be rude or presumptuous, but your other comment seems to indicate that you're not fully understanding the technical workings or implications of a non-disable-able UEFI secure boot).
>They're trying to clean up rootkits that load before antivirus to make their OS more secure.
And that in no way precludes the options that I outlined. To act as if the OEMs act independently or without significant guidance from MS is just misguided.
>Care to tell how?
You seemed to have missed the entire bit about it... preventing non-Windows OSes from being installed. You keep citing the developer tablets that have very obvious needs for having an unlockable UEFI implementation. It's just like Chromebooks (the CR-48 is unlockable, retail units not so much), or Android (fastboot on Nexus, locked on Moto/HTC). I just don't understand how you cite a developer tablet as proof, when it's obvious that Microsoft won't take the step to ensure that the choice is available for consumers. I mean, you even phrase it as "Microsoft got them to..." in reference to the developer tablets.
The Red Hat blogger mentions an unnamed OEM that he claims won't have this option. However, instead of naming that OEM so that we can shame and/or avoid them, he instead wants to shift the blame on to Microsoft. (And then in the same breath, will call Windows insecure coz of the rootkits that load before the anti-malware can).