Linux developers working on uniting Windows 8 Secure Boot fixes

Linux developers working on uniting Windows 8 Secure Boot fixes

Summary: There are now two major ways to boot and install Linux on Windows 8 PCs, but soon they'll only be a single unified method.


Thanks to Microsoft's Windows 8 UEFI (Unified Extensible Firmware Interface) Secure Boot there was no easy way to boot Linux, or any other operating system, on Windows 8 PCs. Now, there are two ways, the recently released Linux Foundation (LF) UEFI secure boot system and Matthew Garrett's shim system to boot Linux on these PCs. Soon, there will be only one unified way.

Soon, loading Linux on a Winodws 8 PC will be as simple as picking a distribution from a menu. (Credit: Gummiboot)

UEFI Secure Boot Linux expert Garrett wrote in his blog, "we now have two signed bootloaders available." The shim method, which Garrett worked on, is now used by Fedora, openSUSE, and Ubuntu. "The LF loader is a different solution to the same problem," said Garrett.

According to Garrett, "One of the primary functional differences between Shim and the LF loader is that the LF loader is based around cryptographic hashes rather than signing keys. This means that the user has to explicitly add a hash to the list of permitted binaries whenever a distribution updates their bootloader or kernel. Doing that involves being physically present at the machine, so it's kind of a pain."

So why did the LF create it then? Garrett explained, "Being hash based means that you don't need to maintain any signing infrastructure. This means that distributions can support Secure Boot without having to change their build process at all. Shim already supports this use case (and some distributions are using it), but the LF loader has nicer UI for managing it."

In addition, Garrett conceded, "Shim implements Secure Boot loading in a less than entirely ideal way - it duplicates the firmware's entire binary loading, validation, relocation and execution code. This is necessary because the UEFI specification doesn't provide any mechanism for adding additional authentication mechanisms. The main downside of this is that the standard UEFI LoadImage() and StartImage() calls don't work under Shim. The LF loader hooks into the low-level security architecture and installs its own handlers, which means the standard UEFI interfaces work. The upshot is that you can use bootloaders like Gummiboot or efilinux [user-friendly UEFI boot menu systems] without having to modify them to call out to Shim."

So, with two different approaches to the same goal, Garrett has decided to merge them together. He's now working on "integrating the LF loader's UI and security code into Shim with the aim of producing one loader that'll satisfy the full set of use cases."

Jame Bottomley, the Linux kernel developer behind the LF UEFI bootloader thinks this is a fine idea. "We’re currently investigating merging them. The main sticking point is the validity of the security override protocol," wrote Bottomley.

Once that problem is fixed, and the usual programming teething troubles are overcome, we'll see a new, unified Linux bootloader for all Intel-based Windows 8 PCs. Neither method, nor the forthcoming unified one, will work on any ARM-powered Windows RT tablet or laptop. Microsoft ARM-powered devices are permanently locked into Windows 8. Still, within the next few months, booting and installing Linux on Intel-based Windows 8 PCs will once more be a matter as simple as putting a Linux CD or USB stick in a PC and re-booting the system.

Related Stories:

Topics: Linux, Hardware, Microsoft, Open Source, Operating Systems, Security, Software Development, PCs, Windows 8

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • The FTL drive is working!

    (That was a Star Trek joke). Most of us will nod our heads at that complicated tech jargon and make believe we understand it completely. Many people will, actually. But as long as the gracious and wonderful geeks do all the hard work, we'll just have to find our ways to thank them.
    P.S. can somebody make me an intergalactic cosmic death blaster? I'm sure it can be done with Linux...
    • this is a geek site

      what are you doing here?
    • They can try that death blaster on Microsoft headquarters

      ...but I think they will complete their self-immolation before the geeks get it built
    • Been there, done that.

      Couldn't release it due to licensing concerns. I may now possess my very own intergalactic cosmic death blaster -- but "Intellectual Property" lawyers still really scare me.
  • So it wasn't a giant scary Microsoft plot after all.

    After all the scaremongering (SJVN right at the helm) it comes down to this - "yes, we can do it, it just took a little time to work out how".
    Not to mention that in the meantime you could just turn off Secure Boot (a feature MICROSOFT mandated as a requirement for Windows 8 logo certification) and go on your merry way, or use an older BIOS based PC (which, given the timeframe, represents the majority of those currently in use).
    I guess this is just one less thing for SJVN to whine about - I suppose next he'll try to get Linux to run in Hyper-V or Azure, find it takes more than 5 minutes and call that a plot against the free world.
    • SJVN Was Right

      Microsoft's making a requirement that it can be disabled does not impress me at all.
      There was no justification whatever that UEFI secure boot works the way it does in the first place. [Don't tell me that I don't know what I am talking about. I have written several secure boot-loaders, and by coincidence, the Rijndael spec is current serving as a coaster for my hot chocolate.] There is absolutely no technical reason that requires that the boot be bound to Microsoft. In other words, to determine whether an image is to be bootable, it should have been a matter of entering the public-key of the entity that signed the image into a table in the BIOS. That's it. Every cryptographer in the world knows to have make it ~NOT~ like that, which Microsoft heavily influenced via their participation in UEFI, means that the requirement might be nothing more than a ruse.

      You cannot tell me that the engineers at Microsoft were not aware of how to do UEFI secure-boot in a way that is not tied to any particular vendor. Microsoft likely did this knowing that many users would be intimidated by the idea of turning off secure boot.
      Le Chaud Lapin
      • They gave you the keys ages ago.

        Get over the FOSS paranoia and use them.
        • No they didn't.

          The RT keys are not the ones that are provided.
        • Shouldn't need THEIR key, except to boot Windows

          And as Le Chaud Lapin points out, any sensible implementation of Secure Boot allows the owner to manage (add, remove, blacklist, etc) whatever keys they choose.

          MS clearly gamed the system, to use Secure Boot as a mechanism to lock out competition, touted as a security measure. And in fact, Microsoft was originally outright forbidding Windows 8 certified computers to even provide Secure Boot disabling at all -- before the outcry forced them to make limited concessions (but only for x86/amd64 cpu architectures).

          And MS hasn't _given_ anyone the keys -- they've in effect merely licensed them, but MS still has the master, and can revoke (blacklist) any provided subordinate keys whenever they choose.
        • Isn't it nice to see...

          ...Steve Ballmer loosing again? He's indeed a looser.
      • Write your own programs!

        If I understand this logic that I have been hearing about for the past year or so. Microsoft is obliged to write programs for the Linux community that the Linux community is too busy to write. Two years ago I suggested that the Linux community would eventually get going and write some code to solve the safe-boot dilemma. Now we see this is occurring.

        Why don't I hear whining about Apple not writing an open EUFI safe boot loader? Or, for heaven's sake, why not Google?

        What I do want to hear about is why there is no hue and cry about the fact that Asus manufactures motherboards with an EUFI Bios that DOES NOT SUPPORT SAFE BOOT!!!!

        Did Asus warn me that their EUFI bios is not safe boot compatible? NO, NO No, it did not.

        If this Vaughn-Nichols dude wants to actually make a contribution, write about the fact that Asus EUFI bios advertising is misleading if not fraudulent. And what about the other EUFI bios's out there. Where are the tests? Is this not a technical web site? Why do we get nothing but tired old rehashed political garbage from Stephen when there is so much computer science to write about?
        • No they didn't.

          They made existing code not work.

          Used nonstandard procedures to block adding our own keys...

          And used different keys than they use to sign other software, such that it still doesn't work.
  • Linux developers doing their bit ...

    ... to make the world more insecure. Stick to Windows 8 and a secure boot loader.
    • Lol

      Sounds like somebody didn't read the article.
    • Oh really?

      Please, enlighten me on the number of Windows viruses compared to Linux viruses.

      And I would avoid the "Linux has less users so less people write viruses for it" argument that folks try to pull every once in awhile; considering that Linux powers the NYSE's machines and quite a bit of the U.S. Department of Defense's machines, I'm sure some cracker would be more than happy to write some piece of malware to infect them... that is, if he *could*.
    • And be inherently insecure.

      You do realize, windows 8 has already been broken.
  • Raise your hand if you told SJVN this would happen

    That linux developers would have to step up and change their OS to comply with modern security standards and in reality it was NOT some evil plot from Microsoft after all.

    I am sure SJVN won't admit this because he is a troll blogger and if the world outside Linux moves forward and does not cater to Linux in it's many forms it must be some consipiracy against Linux when the reality is that technology moves forward and it is up to Linux or any other tech to keep up or be left behind.
    • Where's a gong when you need one?

      You clearly don't have a clue what you're talking about.

      The problem is not UEFI (Linux has been handling that for years) or even Secure Boot, but the maliciously broken implementation that MS encouraged OEMs to put in consumer-grade hardware.

      Microsoft has a history of creating malicious implementations of standards, as a tactic to break interoperability and illegitimately hobble competition. Before Secure Boot there was ODF, before ODF there was Kerberos, etc.

      Microsoft always wrings its hands and bashfully denies any bad intent, but they have the knowledge and skills to fully appreciate what they're doing, and their protestations and excuses always ring hollow to any who have been paying attention.
      • Proof!

        Proof for "maliciously broken implementation" or it did not happen.
  • whew

    glad this will be fixed
    D.J. 43