There are times when I think that there is a special, darkened room at Microsoft peopled by a bunch of guys who seem to have nothing better to do than sit and think up some new wheeze to nobble the opposition. The rap sheet is an inditment in itself: trusted computing, internet driving licenses, DRM, bullying hardware vendors and attempting to strong arm sovereign nation states. You wouldn't think the list could get any bigger. It just has; but then, recidivism in incurable. It may not, as has often proved in the past, come to anything but if it does it would be a problematical for GNU/Linux. The irony is that it may not actually be intentional, but then, the universe is littered with the victims of the law of unintended consequences. So, what's the Hydra's latest head? UEFI. That's what.
Whenever you need to amend the boot order of your computer, say, to configure a newly installed hard drive or to ensure that the CD drive boots your live Ubuntu disk first then you'll be on familiar ground. That of course is the ubiquitous BIOS where you can tweak to your heart's content. If you're adventurous you can risk a flash upgrade. The worst you can say about the BIOS is that, compared to the point-and-click eye candy of today's all singing, all dancing bloated desktops, it looks like it's stuck in a time warp-but at least it does just what it says on the tin.
UEFI: what it is and why Microsoft like it
When you first get your first glimpse of UEFI (United Extensible Firmware Interface. It started life an an Intel specification called just EFI) it looks like somebody dragged the BIOS into the 21st century. Tom's Hardware site has some nice screenshots to give you a flavour. It's point and click pretty and it is claimed that compared to the traditional BIOS it it virtually an instant on boot up. It was also designed to boot large disks (greater than two terabytes), be CPU-architecture independent and modular. So far , so reasonable. However, it still does not solve the problem of the traditional BIOS requiring two drivers-one for the operating system and one for the firmware.
you sense the proprietary wolves beginning to circle and the leader of the opportunistic pack is no other than our old friend Microsoft
It gets interesting however, when you see sense the proprietary wolves beginning to circle and-surprise, surprise-the leader of the opportunistic pack is no other than our old friend Microsoft (a member of the UEFI forum along with Apple). Even if they don't actually innovate a new, restrictive technology they never miss an to opportunity to jump on a bandwagon of one that does. Enter UEFI. So, exactly why would the behemoth of Redmond be so enthusiastic about it? Because mooted changes to the UEFI firmware specification contain the implicit possibility that GNU/Linux would effectively be an "unauthorized" operating system and incapable of booting because those changes would require a digitally signed image derived from a key chain rooted in keys built into a computer and Microsoft would love dearly to make this mandatory. The user could not overide this. Those digitally-signed keys would only be available from Microsoft and the OEMs and GNU/Linux won't boot without them. That would require a signed copy of the keys and while OEMs might play nicely, Microsoft would be sure to decline (whilst also pressuring the OEMs to with hold signed keys to open source operating systems).
This "secure booting" aspect of UEFI presents a potential threat to the open source community and it's inconceivable that Microsoft is unaware of this--despite their own gloss on the matter. You might just be thinking that this is a rerun of the Trusted Computing saga earlier last decade but at least you could run GNU/Linux in that environment.
Cartels aren't popular. Or legal
Much as it galls me to say it, for once Microsoft's motives may not be intentionally sinister. Essentially, the technology is designed to protect against rootkits, malware and other low-level attacks by preventing executables and drivers from being loaded unless they carry a cryptographic signature courtesy of a dedicated UEFI signing key. This would not constitute a specific attack on GNU/Linux as such. After all, secure booting won't allow even Windows users to load Windows 7 either. So, anyone who doesn't want/like Windows 8 won't have the option, unlike predecessors, to revert to an earlier release as people did with Vista and XP. See the electronic landfill sites fill up. (It would be interesting to know if using WUBI or EasyBCD to get the Windows bootloader to dual boot GNU/Linux distros would work with Windows 8. Askubuntu thinks so).
On that reading, Microsoft is spitting in the eye of their own customer base and it occurs to me that Microsoft's secure boot would also prevent Windows users from using recovery and diagnostic software too (though frankly, I can't muster much sympathy for people who pay for the privilege of being persistently shafted. They're being digitally bitch slapped.) Even people who do not use GNU/Linux (or even proselytize for it) will have spotted straight away that European anti-trust laws forbids abuse of market dominance in one area to obtain it elsewhere. Already Linux Australia is considering petitioning the Australian Competition and Consumer Commission (ACCC) on the basis that it is anti-competitive. OEMs will be in the picture too if they lock down secure booting (even if under duress from Microsoft). Cartels aren't popular. Or legal. It has even be mooted, that "hacking" the UEFI may even breach the DMCA.
Now, the eagle eyed amongst you might say: hang on a minute, why single out Microsoft? They're not the only culprits. True. Google's Chromebooks come with verified boot to prevent malware at boot up but at least Google allow the user the option to disable it by entering developer mode. Another case of trusted boot is the One Laptop per Child XO laptop which will only boot from software signed by a private cryptographic key known only to the OLPC non-profit organization. However, the laptop and the OLPC organization provide a way to disable the restrictions, by requesting a "developer key" unique to that laptop over the Internet, waiting 24 hours to receive it, installing it, and running the firmware command "disable-security". The idea is to deter theft of laptops from children or via distribution channels, by making the laptops refuse to boot, making it hard to reprogram them so they will boot and delaying the release of developer keys to allow time to check whether a laptop requesting keys has been stolen.
To balance up things a bit, it has be argued that this is all an hysterical over reaction; a piece of FUD from the FOSS community. Ed Bott thinks so. He argues that Microsoft has no need to trifle with OSes like GNU/Linux that occupy less than five percent of the market, that it will always be niche and that the inability to boot it under UEFI will generate a deluge of irate calls to hardware vendor's support helplines and thus seriously erode razor-thin profit margins on each PC they sell. I actually think that's a very fair point but it fails to address that fact that if Microsoft insist that vendors will not be able to ship Windows 8 without their logo unless they enable secure boot and lock it down then profit margins really would nosedive. They would evaporate.
Bott's article was interesting and challenging. It was just a pity that he chose to quote part of Microsoft's response, a response which included a line which fairly brightened up a wet, dreary autumn day:"At the end of the day, the customer is in control of their PC. Microsoft’s philosophy is to provide customers with the best experience first, and allow them to make decisions themselves". Priceless. For everything else there's GNU/Linux. The title of Bott's article (Why do Linux fanatics want to make Windows 8 less secure?) rather misses the point. GNU/Linux users (fanatics or otherwise) don't want to make Windows less secure. By and large, they don't want to use it at all. Not using it makes them more secure.
GNU/Linux and UEFI: problems and possible solutions
The first thing that needs to be said is that Ubuntu and Fedora, for example, support both UEFI and BIOS firmwares and have done so for some time. Both Canonical and Red Hat are also members of the UEFI Forum so it is inconceivable that they are not fully aware of the implications of Microsoft's thrust but only Red Hat and Canonical sent representatives to the most recent bi-annual plugfest (held at Redmond). An open source input is critical to ensure that Microsoft or Apple don't exert vendor hardware or proprietary software lock in. That said, Microsoft has the kind of financial clout that can reduce a forum to a mere talking shop, a point made by Red Hat's power management and mobile Linux developer, Matthew Garrett. GNU/Linux vendors simply can't match it and therefore influence whether or not hardware vendors release their UEFIs with secure boot locked or disabled. That's the tactics and strategy side of things. What about the technical end of things?
The nub of the problem is that secure booting with Windows 8 effectively means having to run signed code and that's where the open source nature of FOSS comes in: The problem involves GRUB and GRUB 2 bootloaders. They would need to have a signed key included in the bootloader but that would mean embedding proprietary code in those bootloaders and because they are released under the terms of the GPL such modifications would not be permitted. Has the launch of Kernel 3.0, which incorporates GRUB, changed anything? Well, tinkering with GRUB just isn't on regardless of where it is run from. Even so, the Kernel does include closed binary code (from various vendors) which makes source code unavailable. That includes device drivers and modules. Certain distros, like gNewSense, pride themselves on having exorcised all the binary blobs but secure booting will present problems.
What's really required is the ability to disable ’secure boot’ - which could or could not be allowed by the OEMs. You’d need a signed boot loader for Linux and have that key that it is signed with shipped on the system … which is unlikely to happen. Further, Microsoft's new rule for Windows 8 is that any vendor shipping with that logo/device must enable secure boot (but at least, so far, have not insisted that it be locked). I predict that it will only be a matter of time before someone puts up a website listing hardware vendors that offer buyers the option to switch off secure boot (before having their collars felt by the long arm of Redmond).
Ubuntu supports both UEFI and BIOS firmwares
Linux officially support both the UEFI and BIOS firmwares. However Windows supports UEFI only with Vista SP1+ x86_64 and only with GPT partitioning so the open source community is ahead of the game. However, all Dell laptops have bugs in their UEFI firmware preventing them from booting but at least this can be remedied by using the newly released Kernel 3.0 which contains the necessary patches. A problem would arise, potentially, if users wanted to roll their own kernel. Would it automatically include the signed keys? What about booting a GNU/Linux distro running virtually inside a Windows session?
It may also be that the real target is not so much desktops and laptops but smart phones and tablets (at which Windows 8 will be targeted). Given the success of Android on both those platforms it would make sense for Microsoft to try and circumvent anyone attempting to jailbreak those devices to run either their own versions of a GNU/Linux or Android, including dual booting. However, hacking has always been a digital arms race and it is an absolute certainty that whatever locks either Microsoft or hardware vendors invent will be circumvented. That's a given, and whilst it will not deter the seasoned and hardened GNU/Linux users, it will represent yet another obstacle to newcomers adopting it-and all the uber eye candy in the Unity desktop won't get round that initial problem.
The truth of the matter is that this kind of "security through obscurity" just never works
One option to get round all of this is to abandon the GRUB boot loader that uses a GPL license and settle for LiLo (Linux Loader) that uses a BSD license. This enables proprietary code to be incorporated without compromising the terms of the license and although I haven't used LILO since Redhat 9 and early SuSE days, it'still available and under active development. However, although LILO might bypass license issues by using a BSD license rather than the GPL3, it does appear to have significant technical issues with UEFI.
The other option is design a public key for the boot loaders that can be used with the GPL-licensed boot loaders. The computer will be configured to allow these keys but the problem with this approach is that the malware makers will find about this key and the whole idea of secure boot would become non-existent. Don't forget that signed malware is not impossible (for example, the DigiNotar CA compromise. You can envisage a situation where the signed malware gets in, blacklists the official Windows keys and then proceeds to whitelists its own, resulting in a system where you can't remove the virus .. unless you re-jailbreak it. The truth of the matter is that this kind of "security through obscurity" just never works. Sooner or later the code is hacked and they have to build a a better mousetrap.
UEFI is a clear and present danger, intended or otherwise
One final thought: it might not be a bad idea to "stockpile" one very high spec laptop/desktop with a traditional BIOS to temporarily stave off the evil day when you have to bite the UEFI bullet. That should at least future proof matters for quite a few years and if things turn out well the UEFI hurdle will be cleared. I had planned to postpone a purchase of a new laptop until November next year. I might just bring that date forward.
In the meantime I agree with the runes of the blogsphere in the last few weeks. UEFI is a clear and present danger, intended or otherwise. We should be worried but it's not yet quite time to hit the panic alarm and start shouting rape. Not just yet. It all comes down to how the OEMS react so I'm keeping my batteries (and my bank account) fully charged. Just in case.