Shimming your way to Linux on Windows 8 PCs

Shimming your way to Linux on Windows 8 PCs

Summary: Well-known developer Matthew Garrett has just made it easier for Linux to boot on PCs locked down with Windows 8 Secure Boot.

SHARE:
asus-uefi
Garrett's shim method is one giant step closer to making it easy to boot Linux on Windows 8 PCs.

Getting Linux to boot and install on PCs locked down with Windows 8's UEFI (Unified Extensible Firmware Interface) Secure Boot is still a major headache. However, Matthew Garrett, a well-known Linux developer who's been working on fixing the Secure Boot problem, has just released a working UEFI boot solution for Linux distributors. This should enable many more versions of Linux to run on Secure Boot-imprisoned PCs.

Garrett, formerly a Red Hat programmer and now a security developer at Nebula, an OpenStack private-cloud company, announced on November 30th that he was "pleased to say that a usable version of shim is now available for download. … This is intended for distributions that want to support secure boot but don't want to deal with Microsoft."

This approach is not the same as the one that Garrett devised for use with Fedora Linux. That approach uses a Fedora-specific key that's based on a Microsoft/Verisign-supplied Secure Boot key.

While that meant dealing with Microsoft, it was as Garrett had written earlier, "Easy enough for us [Red Hat] to do, but not necessarily practical for smaller distributions." It's also, as The Linux Foundation has found, in its so-far failed attempts to obtain a universal Secure Boot key for Linux distributions, really not that easy at all.

What Garrett has done with his shim approach is to create a signed boot-loader that can add keys to its own database. This is built on SUSE's bootloader design. In the SUSE design, the boot-loader has its own key database, besides the UEFI specification's key database. The SUSE boot-loader then executes any second-stage boot-loaders signed with a key in that database. Since the boot-loader is in charge of its own key enrollment, the boot-loader is free to impose its own policy, including enrolling new keys off a Linux distribution's installation file-system.

Garrett has added the a user-interface to the SUSE second-stage boot-loader. With this, instead of stopping when a here-to-fore untrusted key appears, the user can navigate the available file-systems, choose a key and indicate that they want to add it to the key database. From that time on, the boot-loader will trust binaries signed with that key.

What this means is that Linux, or other operating systems, can "take an existing signed copy of shim and put it on their install media, along with a file containing their key. If a user attempts to boot then the boot will fail because the second stage boot-loader isn't signed with a trusted key, but the user can then use the navigator and select the distribution's key file. After providing confirmation and rebooting, the second stage boot-loader's signature will now be recognized and the installer will boot."

So, for example, with this shim program in place, a user can choose to trust your distro's key and proceed to boot and install it on their Windows 8 PC. Additional security can also be added to this approach to beat back automated attacks.

The shim method is meant for developers to make it easy for end-users to boot and install Linux. It's not meant for Joe or Jane user at home. That said, it should lead to many more distributions being easier to use on Windows 8 PCs.

It does have one disadvantage though for some Linux distributors. Since the shim is a pre-compiled binary, distributions such as Debian, which insist on having full source code availability, may choose not to use it.

Last, but not least, as I've long predicted, implementations of UEFI are making it difficult to boot systems into Linux even when everything else is set correctly. For example, Garrett himself recently ran into a case with a Windows 8 Lenovo Thinkcentre M92p, which installed Fedora, but then wouldn't boot it. In this case, it turned out that UEFI system was checking the descriptive string for each operating system and refusing to run any that didn't call itself either "Windows Boot Manager" or "Red Hat Enterprise Linux."

So, while Garrett's shim will soon be bring many more varieties of Linux to many more Windows 8 PCs, UEFI Secure Boot will remain a significant worry for anyone wanting to run Linux or other alternative operating systems on Windows 8 PCs.

Related Stories:

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

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

Talkback

163 comments
Log in or register to join the discussion
  • Good news

    Any word on why Mr. Garrett could not release his source code?
    John L. Ries
    • It's there

      The source code is in the same directory, and the git repository is at http://www.github.com/mjg59/shim
      mjg59
      • Thanks Matt

        Continue the great work you do...
        .
        RickLively
      • Excellent

        That part of the report did seem odd to me.
        John L. Ries
        • Details

          It's a bit of a subtle thing.

          The shim source code is available and has been the whole time. But to use this particular method, you need to use the precise build of shim that has been signed by Microsoft. That build has been done using the public source, but you can't rebuild it as part of your own project's infrastructure, because the binary you wind up with will not have been signed by Microsoft.

          To use this method of making your distro SB bootable, you have to be okay with just taking the binary build of shim that Matthew provides and using it as-is. If you want to build shim from source as part of your project's infrastructure, you have to get your build of shim signed by Microsoft yourself.
          AdamWill
          • Got it

            RMS probably won't approve, but distributors do what they need to.
            John L. Ries
          • Not just RMS

            Also, the Free GNU/Linux distros approved by RMS, including gNewSense and Trisquel, here:

            http://www.gnu.org/distros/free-distros.html

            As a Debian user, I'll be interested to see where the Debian Project goes with this.
            Rabid Howler Monkey
    • The source code is available...

      But you can't rebuild it and have it work unless you get MS/Verisign to sign the results...
      jessepollard
  • Great to see

    how fast one such solution has come, not from MS who makes secure boot a Win certification requirement to OEMs, but from the open source community. It will be interesting to see how many other solutions will become available before MS can figure out what is wrong with their system for issuing the secure keys. As it has failed.

    Kudos to Matthew Garrett for stepping up to the task!
    coastin
    • Disconcerting to see

      another one getting the facts wrong

      "before MS can figure out what is wrong with their system for issuing the secure keys. As it has failed."

      It has not failed. Garett still had to obtain a key from Microsoft to sign his Suse based bootloader. He *also* had to add a user interface because MS *requires* this from a boot loader before they will issue a signature. Reason: The user must be aware that he/she is now booting a non-Windows operating system.

      This is not a circumvention of Secure Boot. It is fully in compliance with Microsofts requirement for alternative boot loaders. It is just that Garett and (especially) Steven Vaughn-Nichols has been spreading FUD and misinformation about how "draconian" Secure Boot would be.

      MS always intended to allow for chained boot loaders - they just need to present a user interface and require a user action to continue. Otherwise it *would* be a possible circumvention as it could be used to silently boot a malicious host OS and then boot Windows as a (compromised) guest OS without the user being aware of it.

      You see, it has not failed at all. Indeed, this shim boot loader all but illustrates that it has already succeeded. Windows 8 boot path is still protected and 3rd party OSes can still be boot'ed.
      honeymonster
      • Jumping to conclusions

        Keep up or your will get lost.

        ntrolling is speaking about,

        http://www.zdnet.com/linux-foundation-uefi-secure-boot-key-for-windows-8-pcs-delays-explained-7000007841/

        The Linux Foundation is trying to do that but the requirement from MS to OEMs that want to be Win8 certified is they need a MS issued secure key. Linux Foundation has worked it out, even signed the MS required paper contract but MS had a (wink) technical problem in issuing the key to them. They are still waiting for MS tech support.
        daikon
      • eh?

        Er. Where has Matt been spreading misinformation about anything? He's been doing the most work to write code to make distros work with SB.

        This is not a "SUSE-based bootloader", by the way. shim is shim. Matt had the idea of a thin bootloader, signed by Microsoft, which could trust a different signing key for the rest of the bootchain, and wrote it. That is what shim is. SUSE's original plan was to write something much like shim, with the neat refinement that the shim layer could have its own database of trusted keys, rather than just having a single key baked in at build time. Matt thought this was a great idea, and added SUSE's code to shim, so now SUSE can just use shim, without writing their own version of it. But it's more that SUSE's idea and code were merged into shim than that Matt wrote a 'SUSE-based bootloader'.
        AdamWill
      • Disconcerting That Microsoft Has The Authority

        Before you feed me any of the B.S. that you have been feeding others here, you should know that, next to me, is full code for complex symmetric and asymmetric crypto, which I swim in from time to time.

        Garrett Steven Gaughn-Nichols have been telling the truth. There is no technical reason why Microsoft should be chaining anything.

        What really happened is that Microsoft got its tentacles deep into the UEFI design committee, and forced Secure-Boot do be done in a way that makes it problematic, to say the least, to allow secure boot-loading INDEPENDENTLY of Microsoft. There is no reason that the user should not be able to go to a table in the BIOS, and enter the public-keys of the digitally-signed boot images that should be accepted by the BIOS. It is no less secure, and it is actually cleaner from a purists perspective.

        I am looking forward to the day when the U.S. Federal Trade Commission finally gets wind for what Microsoft did and shut this down.
        Le Chaud Lapin
  • Shimming your way to Linux

    Great job Matthew Garrett and the SUSE Team.
    RickLively
  • I suppose this is a good thing.

    I was never on-board with locking h/w to specific OS'. That being said, doesn't this workaround semi-negate the idea of securing boot altogether (sort of like throwing the baby out with the bathwater)? Instead of maintaining a not-altogether-bad idea for boot threats, it simply circumvents it completely, instead.
    In other words, is Linux that fragmented as to not implement their own iteration of this technology due to the sheer amounts of various distros? It's a workaround, not a fix.
    TechNickle
    • --

      How is it a work around and not a fix?
      RickLively
      • It's not a fix because...

        ...it was never broken.
        PollyProteus
    • That is being stalled right now

      by a tech support problem at MS. Check the article here titled: "Linux Foundation UEFI Secure Boot key for Windows 8 PCs delays explained" Link above reader comments.

      The Linux Foundation is trying to do that but the requirement from MS to OEMs that want to be Win8 certified is they need a MS issued secure key. Linux Foundation has worked it out, even signed the MS required paper contract but MS had a (wink) technical problem in issuing the key to them. They are still waiting for MS tech support.
      coastin
      • Thanks.

        Makes sense now. Thanks.

        Also, sure would edit out my wording about Linux "fragmentation". That definitely looks worse written, than it was meant while writing it.
        TechNickle
        • Don't worry about it bunnyslippers...

          You are absolutely spot on; as a very long time user of, and believer in Open Source coding (my first install was debian potato) the open source community is splintered/fractured/moving in different directions/whatever-term-you-like by design. This is the whole point of the journey. There is no bill or steve at the helm guiding you through the storm, rather a collection of nomadic groups that each want to do what they want to do and meat up each year to share their knowledge. An intensely organised, regulated hiarachical structure set out on a clear path is a total contradiction to the cause. That's what distro's do. By and large a distro just compiles all the bits of freely available code and pcakages and steers it in the direction it wants to go; many such as ubuntu in a relatively organised and structured way. They then release their code and distro's that like it use it in their distro's. the idea is that by all making what we want, we all advance as one and everyone is happy.

          Of course that's the ideal and no ideal can be shared by all; distro's squabble, fall-out, fork all the time; temprimental dev's hop ships left right and center, but the fleet does keep moving.

          It's best to think of open source os as a tree; the seed they all came from was bsd, but we've now ended up with roots made from the gnu userland, the linux kernel, the hurd kernel, freebsd, netbsd, openbsd, minix, openindianna as well as non unix such as beos and windows open source projects. Then you have the trunk where all the knowledge is pooled and shared and the branches of distro's building packages and feeding it all back to the trunk.

          It's fractured by design. It's not offensive to say so. :-)
          MarknWill