A Developing UEFI Secureboot Situation

We've been working to provide an alternative to the Microsoft key, so
that the entire free software ecosystem is not dependent on Microsoft's
goodwill for access to modern PC hardware. We originally flagged the
UEFI / SecureBoot transition as a major problem for free software, we
lead the efforts to shape the specification in a more industry-friendly
way, and we're pressing OEM partners for options that will be more
broadly acceptable than Red Hat's approach.
SecureBoot retains flaws in its design that will ultimately mandate that
Microsoft's key is on every PC (because of core UEFI driver signing).
That, and the inability of SecureBoot to support multiple signatures on
critical elements means that options are limited but we continue to seek
a better result.
Mark

It would seem that Canonical is putting more thought into the UEFI Secureboot situation and not jumping to the conclusion of buying a Microsoft Key which appears to be the “Red Hat Way” if you will. It will be interesting to see how the Open Source Community as a whole addresses the Windows 8 UEFI Secureboot concerns and how OEM’s will respond both to Microsoft’s demands and the Open Source Communities requests.
Surely other communities such as Linux Mint, Arch and Debian must also be wondering how they will proceed?

Fedora isn’t exactly a profit center for Red Hat. Also, in his post that started this most recent discussion, Garrett said Microsoft-style Secure Boot won’t apply to server hardware. Of course, who knows what that means.

I suspect we will see major Linux users — Google, for example — either avoid purchasing new hardware that’s compliant with Secure Boot, or just disabling it as a matter of policy. I can’t imagine Google or anyone else with a major commitment to Linux wanting to use Secure Boot if that’s accompanied by a de facto dependence on the key master, whether that’s Microsoft or Canonical.

If, in the near future, we see the Windows universe on Secure Boot and free from pre-boot attacks, and the Linux universe running with it disabled and, hence, the target of pre-boot attacks, we could see Linux stigmatized by the Windows universe as an insecure OS.

Or Google will just install their own keys. they already use their own BIOS for chromebook, and AFAIK, their policy is to store nothing on their laptops ( even if I think that’s not a policy for the whole company ), so they could just use chromebook for them.

If google decides to self-sign.. well that just brings the single signature limitation into sharper focus. Equipment vendors that have to release firmware/driver blobs signed with keys for both MS and Google and Canonical and whoever else…. is just unnecessary duplicative work. If Google decides to do like Canonical is doing things are going to bit very very messy for device manufacturers. Even messier for ARM than Intel.

no no no, please take the time to understand this stuff, spouting FUD like that doesn’t help anyone. Red Hat will pay $99 once, to Microsoft, who will pass it on to Verisign. That will give Red Hat a signed bootloader that they can give to Fedora to freely redistribute to everyone. Red Hat takes the hit for the $99, it is not a per-customer tax. The money is not the issue.

also remember this is just for OEM pre-installs. Not the regular aftermarket CD. It is entirely possible and reasonable to speculate that Canonical might be ponying up the $99 to sign the bootloader and kernel for the regular Ubuntu CD.

I am sure they will need to do that if they want easy install on machines with preloaded Windows 8 and not Ubuntu. Why? as explained by Matthew Garrett UEFI only allows one siganture per binary, so Canonical force users to disable SecureBoot or install their key manually, or provide different media for Windows machines. If thwy sign their install media with Ubuntu key, that will not boot on Windows 8 machines without complex user intervention on the UEFI setup screens, because you can not sign with both Ubuntu and Microsoft keys

The traditional linux “aftermarket” is definitely going to be problematic for everyone once secureboot enabled hardware starts hitting retail shelves from the mass market OEMs.

Now I certainly have the technical ability to poke around in bios level config screens and twiddle settings which would disable secureboot before installing linux. But I live in the 0.01% tail of technical proficiency. I do not expect even enthusiast users to want to do this sort of stuff just to install linux side by side with windows in a dual boot config

Most people won’t even know how to approach it. And certainly not the less technical user who gets install media from an Ubuntu advocate at a random event or through just word of mouth. Friends and neighbors in a year or two who want to give this Ubuntu thing a try based on your recommendation as their “friend who knows computers” are going to be stymied by secureboot enabled hardware that they own. Their inability to get Ubuntu installed and working will look like an Ubuntu install failure to them. They’ll just boot back to windows feeling like they gave Ubuntu a fair shot.

If Canonical can get OEMs using their key on pre-installs that great for them and their OEM business division. And long term it will definitely keep the pressure up on getting this spec revised for future hardware to solve the single signature bottleneck. But we are realistically talking about a 2 year lead time. 2 years where secureboot hardware will be out in the wild for people to purchase. For the more common Ubuntu “aftermarket” distribution and usage scenario… whatever Canonical spins up as an alternative signing authority to MS’s is not going to solve the problem in the near to medium term.

I would love to see Canonical solve that aftermarket distribution problem in a different way than the Fedora proposal. I really would. I just don’t see how that’s possible given the constraints without making the end-users jump through a lot of hoops to get an aftermarket linux installed on ostensibly working secureboot enabled hardware that is running windows with no problem since purchase. It would be a uncharacteristically unpragmatic decision for Ubuntu as a project to take an ideological hard line over limitations in the technology specification.

Red Hat didn’t “jump to the conclusion” – they thought it out. This is straight up fud. The Red Hat decision makes sense – but I guess you could pony up the millions of dollars to maintain your own set of keys as opposed to paying $99 once..

And if that really yanks your chain – just generate your own keys for your own machines.

Made with haste ? You may have missed lots of stuff :
1) the article of mjg is a proposal ( ie, still being discussed ), with the aim of having maybe a better proposal ( but since there is nothing good enough, this will likely be adopted )

I don’t think a solid in stone decision has been made when it comes to Ubuntu based on discussions I have had with people at Canonical and based on Mark Shuttleworth’s recently saying “We Continue To Seek A Better Result”. Ultimately we will see how it progresses in this either 12.10 or future releases.

Technically, that’s still a proposal made by Fedora, not a decision, since the feature was not approved by FESCO so far, to let the time for a proper debate ( ie there isn’t much people happy with this, but no one found a better idea except “do nothing” )

Uhm… the ubuntu-devel-list thread referenced here seems to be missing some discussion. It seems Mark cross posted his response..quoting from another post. I have no idea if that is a selective qoute or if its the full post from the author Mark is responding to.

I would very much like to read the original discussion for reference. Any idea where the original discussion thread is that Mark cross-posted?

new update from Canonical. I do not understand the reasoning being used that secureboot enabled systems will _not_ require signed linux kernels or singed kernel driver binaries. This runs counter to my current understanding of how secureboot is suppose to work. Can anyone add some additional information about the necessity or lack there of kernel signing?