Ubuntu system may be more locked down than a certified Windows 8 system

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

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

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.

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.

http://lxer.com/module/newswire/view/168551/index.html

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?

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.

The more I look at Secure Boot the less I like it. Too many questions and obvious flaws.

Plus it can probably be circumvented with a paperclip and a tin of beans.

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

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?

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

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

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.

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

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.

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

@CFWhitman

So, if I understand this correctly, "binary blobs" are about to become a much bigger issue?

I think that's a fair assessment... But aren't most binary blobs provided by the distro repositories?

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

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.

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.