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.
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:
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
The FTL drive is working!
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
They can try that death blaster on Microsoft headquarters
Been there, done that.
So it wasn't a giant scary Microsoft plot after all.
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
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 this...so 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.
They gave you the keys ages ago.
No they didn't.
Shouldn't need THEIR key, except to boot Windows
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...
Write your own programs!
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.
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 ...
Lol
Oh really?
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.
Raise your hand if you told SJVN this would happen
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?
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!
whew