A Developing UEFI Secureboot Situation

I was quite pleased with Mark Shuttleworth’s recent response to a Ubuntu User recently regarding how Canonical will approach the 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.


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?


  1. ZoubIWah says

    at least more than RedHat’s “its ok customers will pay $99 tax to microsoft to be able to boot non-windows OS”

    Wondering if RH gets a dime on it or what.

      • jon_downfromthetrees says

        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.

        • Michael says

          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.

          • says

            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.

    • AlanBell says

      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.

  2. AlanBell says

    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.

    • Robert says

      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

    • says

      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.


  3. bittercode says

    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.

    • says

      Thought it out yet they were the first distro to day a one-off payment to get the key while everyone else is still seeing what the best approach is…. seems like a decision made with haste to me.

      • Michael says

        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 )

        2) the whole UEFI stuff have been announced since at least october 2011 ( http://mjg59.dreamwidth.org/6503.html ) and mjg have had all the time to ponder his proposal.

        ( not to mention that both Canonical and Red Hat representatives have been present in various meeting of the UEFI forums, as said by the Canonical press release and various mails on Fedora-devel )

        • says

          1. It does not appear to be a proposal but instead a done deal or one with high probability ( http://mjg59.dreamwidth.org/12368.html)

          2. Nobody is disputing that UEFI was announced in 2011 but just because a year has gone by does not make a good argument as to rushing to get a Microsoft key.

          3. Yep I’m quite aware of the discussions that have occurred on the matter but still you do not see anyone except Fedora concluding that getting a Microsoft key is the only way to go.

          What role do you play in development of other distro? Just wondering.

          • Matthew Garrett says

            Taking 9 months to consider all options and come to a conclusion is hasty, but taking 9 months and three weeks isn’t?

    • Michael says

      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” )

  4. says

    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?


    • says

      I believe the individual wrote him in private and Mark decided to reply with ubuntu-devel cc’ed so that he perhaps did not have to respond to it again in the future?

  5. says

    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?


    • says

      I’m unsure why it would need to be signed? Were talking security at boot level (or so they say) so the Kernel should not play a part in Secureboot imo but let me ask someone.

    • says

      So I just spoke with someone who co-authored today’s announcement and he said the kernel does not need to be signed because the spec does not require it.