disable Secure Boot
|
| Author | Content |
|---|---|
| tuxchick Jun 19, 2012 5:22 PM EDT |
Disable it, or shop for hardware where it is not enabled by default. Its security benefits are entirely theoretical and unproven, and in fact there are multiple reasons to not trust it, and MS' implementation is all about locking out competitors. Look at all the troubles it's causing-- it is far from ready for prime time, even if it really is a useful security measure. Which I doubt. |
| albinard Jun 19, 2012 5:50 PM EDT |
What is the latest word on the possibility of disabling? Apparently it is to be possible on a Canonically-blessed (talk about the cathedral instead of the bazaar!) PC, but has Microcosm yet said whether they will insist their slaves produce only disable-proof boxes? And another issue I haven't heard discussed: for the DIY crowd, are components going to be pre-flashed with UEFI? That would be an exceptionally low blow, which is why I fully expect it. |
| JaseP Jun 19, 2012 6:02 PM EDT |
M$ has made it the spec,... But I suspect that part of Win8 certification is optional, and the OEMs have the ability to deviate. |
| pmpatrick Jun 19, 2012 6:17 PM EDT |
Quoting:What is the latest word on the possibility of disabling?For PC hardware, MS specs require that the user be able to disable secure boot. That requirement is not present for ARM based hardware, however. |
| BernardSwiss Jun 19, 2012 6:49 PM EDT |
Am I missing something?Quoting: It must be possible for the end user to reconfigure keys This appears to be significantly different than the case with Microsoft. Microsoft rather coyly does not in fact include this (ie. a requirement that the user be able to manage Secure Boot keys in their UEFI) in the Windows certification requirements -- which is the substantial basis for it being an issue at all, in the first place. If the user (aka "owner") can reliably manage keys in the UEFI -- then doesn't the fundamental problem go away? Ubuntu wouldn't need to supply a signing service, because users could sign their own software (or maybe even use some key supplied by some other particular distro -- even one from Fedora or Red Hat). Of course, Microsoft is already insisting that Windows-certified ARM hardware shall not permit key management, nor even disabling Secure Boot. Is Ubuntu making up different rules for certifying ARM vs x86 hardware? |
| Fettoosh Jun 19, 2012 11:54 PM EDT |
Quoting:Matthew Garrett sums up these requirements. He says, in a nutshell, the requirements for secure boot are: There is so much misinformation it is getting really ridiculous. "It must be possible to disable secure boot" was never a requirement by MS. On Intel x86, MS left up to the OEMs to decide on. the requirement MS made was to not allow users to disable Secure Boot". Quoting:Michael Hall said during a discussion on Google+ that they will find a solution once Windows 8 devices start hitting the market. That is the best approach to take because no one really knows what MS & their lackey OEMs final decisions are going to be. Also, the wordings of some of the comments are not specific enough. "Secure Boot" will only control the OS boot process, and it has nothing to do with other software/applications that run on top of the OS. May be it will control drivers and software that needs direct hardware accesses, but is doesn't influence applications that don't directly access hardware. May be everyone should be a little more careful and specific so we don't spread more false information. I too personally will not be paying any attention to all that until Windows 8 hit the market. |
| JaseP Jun 19, 2012 11:57 PM EDT |
M$ has stated that the spec should be that a user be able to at least disable the UEFI secure boot feature ... Of course, M$ is particularly lenient with OEMs that deviate from spec, in their favor... I trust them as far as I can throw them... Actually, a little less,... |
| tuxchick Jun 20, 2012 12:18 AM EDT |
Come on, gang, I did all the hard work for you :) Like reading the actual Windows 8 certification spec, which requires that Secure Boot can be disabled by the user, and that users can install whatever signing keys they want, but only on x86 hardware. http://lxer.com/module/newswire/view/168551/index.html That same spec requires that vendors who want the Windows 8 certification on ARM hardware cannot allow Secure Boot to be disabled. Originally MS wanted the same requirement for x86. That same article explains in more detail why I think UEFI Secure Boot is security theater, and MS is up to their same old anti-competitive tricks. I really hate to see Linux distros validating something as shaky as UEFI Secure Boot as a legitimate and trustworthy security measure. Nobody but me and a few other lone cranky voices are even questioning it. A shorter, rantier version appeared on LXer; a lot of readers got distracted by the whinging at Red Hat, but it also questions the security claims made by Secure Boot proponents. http://lxer.com/module/newswire/lf/view/168183/ |
| tracyanne Jun 20, 2012 12:22 AM EDT |
Quoting:What is the latest word on the possibility of disabling? Apparently it is to be possible on a Canonically-blessed (talk about the cathedral instead of the bazaar!) PC, but has Microcosm yet said whether they will insist their slaves produce only disable-proof boxes? Then always buy Canonically-blessed hardware. The benefit is this will not be a Microsoft sale, and.... you can be certain any other Linux based OS will run on the hardware. Seriously it's a no brainer. That, by the way, is pretty much what I do. I purchase from an Australian factory (they're in Sydney) that offers windows Ubuntu and No OS, so I can be certain of 2 things, if I buy with Ubuntu pre installed. 1) it works with any other Linux OS, and 2) it's not a Windows sale. |
| Fettoosh Jun 20, 2012 12:33 AM EDT |
@JaseP, I believe MS did NOT require "Secure Boot" to be open for the user to disable it on Intel platform. It basically left it up to the OEMs discretion to lock it or not to lock it. That is different from requiring/demanding it to be open to be disabled by users. Isn't that why Matt was so concerned that some OEMs indicated that they might not have the option for the user to disable it? If that wasn't the case, we should have nothing to worry about and Matt's workaround shouldn't be necessary any more. |
| Fettoosh Jun 20, 2012 12:41 AM EDT |
Quoting:Originally MS wanted the same requirement for x86. That is what I thought too. Things are changing and I believe they will change some more when the brown stuff hits the fan. :-) |
| Fettoosh Jun 20, 2012 12:47 AM EDT |
In terms of PC, I will only buy ones that come with NO OS and NO UEIF And in terms of tablets running ARM, I will NOT buy any but the ones that come with Vivaldi/Spark. |
| BernardSwiss Jun 20, 2012 2:18 AM EDT |
I just learned a little earlier today, on Matthew Garrett's blog, that as of last December, Microsoft did in fact change it's official Windows 8 certification/specification, to require OEMs to ship x86 Windows 8 systems with key-management features accessible to the user in the UEFI.Quoting:Come on, gang, I did all the hard work for you :) Like reading the actual Windows 8 certification spec, which requires that Secure Boot can be disabled by the user, and that users can install whatever signing keys they want, but only on x86 hardware.Yes Tuxchick, yes, you did indeed. But when I saw that part of your article, I assumed that it was just a misleading sentence construction, and that you didn't really mean to say that we could count on OEMs shipping Win8 (x86) systems with real key-management options. Well, I was wrong about that. The news of Microsoft's about face was surprisingly (amazingly) muted -- and I managed to miss it. The news was so muted that the small, quiet references I came across seemed misprints and bad construction, and, occasionally, just more-likely-than-not misinformed. Even the click-bait "pop-tech" press and blogs were really quiet about it (Botts had a short piece, but I stopped listening to, let alone taking him seriously on, anything he says about Linux, quite a while ago.) Anyways, I still don't see how Ubuntu is "more locked down than Windows 8". But maybe I'm missing something else? |
| tuxchick Jun 20, 2012 4:05 AM EDT |
Quoting: I still don't see how Ubuntu is "more locked down than Windows 8". But maybe I'm missing something else? No, you're not missing anything. The article is wrong. The difference between Fedora and Ubuntu is anyone can use Microsoft's signing service, including Linux distros. That's what Fedora is paying $99 for-- the relevant Fedora binaries will be signed with Microsoft's key, and verified by MS' root certificate authority, which is Verisign. If Ubuntu PCs are shipped with Canonical keys and Secure Boot on, and Canonical does not also offer a public signing service, then users won't be able to boot any other operating systems without disabling Secure Boot. The reason for this stupid state of affairs is the Secure Boot spec only allows for a single signing key on a system. However, if you read Canonical's own BIO/UEFI spec for OEMs, there is a distinct flavor of un-enthusiasm for Secure Boot. See section 9.5 http://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf Canonical does not require that Secure Boot be on by default, and they do require that users can do what they want with it. I suppose you could argue that any vendor shipping Ubuntu PCs with Secure Boot on by default results in a more-locked down system. But it's a weak argument given that Canonical does not require it. |
| tuxchick Jun 20, 2012 4:08 AM EDT |
The more I look at Secure Boot the less I like it. Too many questions and obvious flaws. |
| jacog Jun 20, 2012 4:28 AM EDT |
Plus it can probably be circumvented with a paperclip and a tin of beans. |
| JaseP Jun 20, 2012 12:00 PM EDT |
Per that PDF, page numbered 26 of the document specifies that any Ubuntu certified device requires that you, as user can add your own keys... For signing your own custom kernels, for example... Looks like a Ubuntu device IS more free, and LESS locked down... So the article is essentially wrong... |
| Fettoosh Jun 20, 2012 12:11 PM EDT |
One question thou, what does "as user can add your own keys" mean? is it just a confirmation to a question? If not, how involved is it to an average user? Since Secure Boot is just a sliver of the whole security issue, why would one need to go through all the trouble if the user can just disable the don thing and forget about it? |
| jdixon Jun 20, 2012 12:20 PM EDT |
> Since Secure Boot is just a sliver of the whole security issue, why would one need to go through all the trouble... Some government contracts will require a secure boot capability. For your average user it's probably not worth the hassle. |
| JaseP Jun 20, 2012 12:35 PM EDT |
Yeah,... agreed. The easy button is to disable secure boot,... But for those that want it,... and want custom kernels, etc., forcing the option to allow user-generated keys is the best fix. My only question is how a user will generate and distribute those keys,... I have seen very little on how keys are generated, and if a tool would be available to do so... Or even,... how that process works... |
| CFWhitman Jun 20, 2012 2:05 PM EDT |
According to Matthew Garrett's blog, it seems that the Microsoft requirements are that OEMs either allow Secure Boot to be disabled or allow the addition of new keys, not both (although both would be acceptable, it does not appear to be required). Really, for Secure Boot to be more than just a sham and a tax, it needs to have the ability to both add and remove keys (who's to say that any key might not be compromised at some point, especially a widely used one). I don't think that Secure Boot is practical at the moment since it apparently only allows one key at a time, and it's clear that it would be much more useful to have the ability recognize multiple keys when desired. With all the additional overhead of signed peripheral hardware/drivers it's hard to believe that Secure Boot won't be more trouble than it's worth for most people. |
| BernardSwiss Jun 20, 2012 3:15 PM EDT |
@CFWhitman Where are you getting the part about "only allows one key at a time" from? That would certainly be additional and totally unnecessary hassle. |
| Fettoosh Jun 20, 2012 3:24 PM EDT |
Quoting:Some government contracts will require a secure boot capability. Someone needs to explain to those lazy bones that "Secure Boot" is not what it is being advertise to be, and, it doesn't give them what they think they are getting before it is too late. |
| CFWhitman Jun 20, 2012 5:15 PM EDT |
@BernardSwiss I'm sorry. That wasn't clear. It only allows software (including peripheral firmware) to be signed with one key at a time. It's not as big of a hassle as only allowing one key in motherboard firmware, but it's not the most convenient feature either, since it affects the firmware for peripherals. That is, firmware loaded onto a card from the operating system has to be signed, and it can only be signed with one key, so you can't load firmware for a card in your system unless your motherboard firmware recognizes the key in that firmware, probably the Microsoft key. To quote Matthew Garrett: Quoting:This leads to the problem. The Authenticode format used for signing UEFI objects only allows for a single signature. If a driver is signed by Microsoft, it can't be signed by anybody else. Therefore, if a system vendor wants to support off-the-shelf PCI devices with Microsoft-signed drivers, the system must carry Microsoft's key. If the same key is used as the root of trust for the driver signing and for the bootloader signing, that also means that the system will boot Windows. I should also add that this of course means that you can't have an operating system kernel signed to work with both the Microsoft key and another key (like the Ubuntu key). So if you have a system that has only one key, then your operating system has to be signed with that key and that key only. |
| BernardSwiss Jun 20, 2012 6:59 PM EDT |
@CFWhitman So, if I understand this correctly, "binary blobs" are about to become a much bigger issue? |
| JaseP Jun 20, 2012 7:29 PM EDT |
I think that's a fair assessment... But aren't most binary blobs provided by the distro repositories? |
| jdixon Jun 20, 2012 9:18 PM EDT |
> So, if I understand this correctly, "binary blobs" are about to become a much bigger issue? That's an interesting question. And kernel modules in general are aslo an interesting question. Obviously, kernel modules which are loaded at boot time must be signed. But what about modules loaded after the fact, including those with binary blobs? If the secure boot code is checked every time you add a device while the machine is running and it loads a kernel module, things could get really interesting, but I don't think that's the case. |
| gus3 Jun 20, 2012 10:23 PM EDT |
Let's throw into the mix: -- hot-plugged PCI-Express devices, and their modules/drivers, -- built, installed, and loaded without a reboot. As in, "built after-the-fact," perhaps as a kernel patch or an out-of-tree source tarball. And that driver has to be submitted for signature before a skilled sysadmin will be "allowed" by Microsoft('s lackeys) to use it? The TOS prohibits me from expressing my response to such insanity. |
| CFWhitman Jun 21, 2012 9:23 AM EDT |
It's not entirely clear by the language used, but I don't think it's actually the driver that has to be signed. I think it's dynamically loaded firmware that may be shipped with the driver. This is common for wireless network cards, but could be there for other peripherals as well. If the firmware is on a flash ROM on the card, then it shouldn't matter for running the card, but firmware re-flashes to cards may be (probably will be) affected. I could be misreading this, however. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!