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.
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:
- Linux Foundation UEFI Secure Boot key for Windows 8 PCs delays explained
- Linux Foundation support for booting Linux on Windows 8 PCs delayed
- Ubuntu Linux adopts new UEFI boot problem approach
- Linux developers working on Windows UEFI secure boot problem
- Shuttleworth on Ubuntu Linux, Fedora, and the UEFI problem
- Another way around Linux's Windows SecureBoot problem
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Good news
It's there
Thanks Matt
.
Excellent
Details
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.
Got it
Not just RMS
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.
The source code is available...
Great to see
Kudos to Matthew Garrett for stepping up to the task!
Disconcerting to see
"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.
Jumping to conclusions
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.
eh?
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'.
Shimming your way to Linux
I suppose this is a good thing.
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.
--
It's not a fix because...
That is being stalled right now
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.
Thanks.
Also, sure would edit out my wording about Linux "fragmentation". That definitely looks worse written, than it was meant while writing it.
Don't worry about it bunnyslippers...
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. :-)
Wow, incredibly well put, MarknWill