Monthly Archives: November 2012

The ARM Windows 8 Lockdown

A lot of people have been asking why the Linux Foundation is concentrating on making sure there’s a Linux Boot solution for Windows 8 PCs that’s compatible with the GPLv3 requirements and not really doing anything about ARM (for which the current Windows 8 hardware requirements mandate no ability either to turn off secure boot or to replace the keys).

The answer to this comes in several parts: firstly in the PC space, Microsoft has an effective headlock on the OEM and ODMs: no desktop PC ships without a Windows compatibility sticker (the situation is different in the server market, but this is specifically about desktop PCs).  Therefore in order to continue simply booting Linux on laptops and desktops, it is a huge priority to find a solution to this problem.  Secondly: in the overall mobile marketplace, which encompasses tablets and smartphones, Microsoft has a very tiny presence: somewhere between 2-5%.  Linux (Android) has the majority presence: by some counts, Android is >50% in this market space with Apple a close second.  Therefore, a Microsoft mandate in an industry where they have no dominance is simply not really threatening (unlike the PC space where they have complete dominance).

The third problem is more philosophical: all Apple phones and tablets are locked down via cryptographic or other means (it’s not exactly the same as the UEFI secure boot lockdown, but it is similar) so it seems unreasonable to attack Microsoft but not Apple for doing this.  Additionally, a lot of Android devices also come locked down out of the box, so we haven’t even got our own house in order yet.  HTC and Samsung have bought into the argument that a flourishing mod rom ecosystem aids sales of mobile devices, so a growing number of Android phones ship with the oem unlock functionality (which turns off the boot lock in exchange for voiding the warranty) and thus we’ve been making considerable headway opening up the Android mobile ecosystem to the mod roms.  In this instance, I’d like to proceed with the economic argument and use persuasion to make at least the Android ecosystem more open.  Since Apple wants to retain a tight leash on what they regard as their hardware, I can’t ever see them doing anything other than battle with their mod rom ecosystems, and Microsoft is pretty much of the same mind set.  In the long run it cuts them off from external sources of innovation and limits their horizons to what their in-house engineers can think of, so I really believe that having Microsoft and Apple employ lockdowns will actually contribute, at least in part, to the rise of Linux on mobile devices.

The final argument is pragmatic: every apple phone and tablet has been rooted within a few weeks of release, so in practical terms, using cryptographic methods to lock determined users out of their own hardware is ineffective.  It’s actually rarely the cryptographic protection that’s broken; most often the rootkits exploit bugs and problems in the actual boot sequence itself.  So if the Surface (or Windows phone) hardware is really enticing, I’ve no doubt we’ll see a Linux variant running on it in the near future regardless of UEFI secure boot.

Adventures in Microsoft UEFI Signing

As I explained in my previous post, we have the code for the Linux Foundation pre-bootloader in place.  However, there was a delay while we got access to the Microsoft signing system.

The first thing you have to do is pay your $99 to Verisign (now Symantec) and get a verified by Verisign key.  We did this for the Linux Foundation, and all they want to do is call head office to verify. The key comes back in a URL that installs it in your browser, but the standard Linux SSL tools can be used to extract this and create a usual PEM certificate and key.  This is nothing to do with UEFI signing, but it’s used to validate to the Microsoft sysdev system that you are who you say you are.  Before you can even create a sysdev account, you have to prove this by signing an executable they give you and upload it.  They make strict requirements that you sign it on a specific Windows platform, but sbsign worked just as well and bingo our account is created.

Once the account is created, you still can’t upload UEFI binaries for signature without first signing a paper contract.  The agreements are pretty onerous, include a ton of excluded licences (including all GPL ones for drivers, but not bootloaders).  The most onerous part is that the agreements seem to reach beyond the actual UEFI objects you sign.  The Linux Foundation lawyers concluded it is mostly harmless to the LF because we don’t ship any products, but it could be nasty for other companies.  According to Matthew Garrett, Microsoft is willing to negotiate special agreements with distributions to mitigate some of these problems.

Once the agreements are signed then the real technical fun begins.  You don’t just upload a UEFI binary and have it signed.  First of all you have to wrap the binary in a Microsoft Cabinet file.  Fortunately, there is one open source project that can create cabinet files called lcab. Next you have to sign the cabinet file with your Verisign key.  Again, there is one open source project that can do this: osslsigncode. For anyone else needing these tools, they’re now available in my openSUSE Build Service UEFI repository. The final problem is that the file upload requires silverlight.  Unfortunately, moonlight doesn’t seem to cut it and even with the version 4 preview, the upload box shows up blank, so time to fire up windows 7 under kvm. When you get to this stage, you also have to certify that the binary “to be signed must not be licensed under GPLv3 or similar open source licenses”.  I assume the fear here is key disclosure but it’s not at all clear (or indeed what “similar open source licences” actually are).

Once the upload is done, the cabinet file goes through seven stages.  Unfortunately, the first test upload got stuck in stage 6 (signing the files).  After about 6 days, I sent a support email in to Microsoft asking what was going on.  The response: “The error code thrown by our signing process  is that your file is not a valid Win32 application? Is it valid Win32 application?”.  Reply: obviously not, it’s a valid UEFI 64 bit binary.  No further response …

Tried again.  This time I got a download email for the signed file and the dashboard says the signing failed.  Downloaded and verified.  The binary works on the secure boot platform and is signed with the key

subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011

Asked support why the process was indicating failed but I had a valid download and, after a flurry of emails, got back “Don’t use that file that is incorrectly signed. I will get back to you.”  I’m still not sure what the actual problem is, but if you look at the Subject of the signing key, there’s nothing in the signing key to indicate the Linux Foundation, therefore I suspect the problem is that the binary is signed with a generic Microsoft key instead of a specific (and revocable) key tied to the Linux Foundation.

However, that’s the status: We’re still waiting for Microsoft to give the Linux Foundation a validly signed pre-bootloader.  When that happens, it will get uploaded to the Linux Foundation website for all to use.