Red Hat‘s Matthew Garrett let the cat out of the bag about a month ago: when UEFI Secure Boot is adopted by mainboard manufacturers to satisfy Microsoft Windows 8 requirements, it may very well be the case that Linux and others (BSD, Haiku, Minix, OS/2, etc) will no longer boot.
Matthew has written about it extensively and seems to know very well what the issues are (part I, part II), the details about signing binaries and why Linux does not support Secure Boot yet.
The Free Software Foundation has also released a statement and started a campaign, which is, as usually, anti-Microsoft instead of pro-solutions.
Now let me express my opinion on this matter: this is not Microsoft’s fault.
Facts
Let’s see what are the facts in this controversy:
- Secure Boot is here to stay. In my humble opinion, the idea is good and it will prevent and/or lessen malware effects, especially on Windows.
- Binaries need to be signed with a certificate from the binaries’ vendor (Microsoft, Apple, Red Hat, etc)
- The certificate that signs those binaries needs to be installed in the UEFI BIOS
- Everybody wants their certificate bundled with the UEFI BIOS so that their operating system works “out of the box”
- Given that there are many UEFI and mainboard manufacturers, getting your certificate included is not an easy task: it requires time, effort and money.
Problem
The problem stems from the fact that most Linux vendors do not have the power to get their certificates in UEFI BIOS. Red Hat and Suse will for sure get their certificates bundled in server UEFI BIOS. Debian and Ubuntu? Maybe. NetBSD, OpenIndiana, Slackware, etc? No way.
This is, in my humble opinion, a serious defect in the standard. A huge omission. Apparently while developing the Secure Boot specification everybody was busy talking about signed binaries, yet nobody thought for a second how the certificates will get into the UEFI BIOS.
What should have been done
The UEFI secure boot standard should have defined an organization (a “Secure Boot Certification Authority”) that would issue and/or receive certificates from organizations/companies (Red Hat, Oracle, Ubuntu, Microsoft, Apple, etc) that want their binaries signed.
This SBCA would also be in charge of verifying the background of those organizations.
There is actually no need for a new organization: just use an existing one, such as Verisign, that carries on with this task for Microsoft for kernel-level binaries (AuthentiCode).
Given that there is no Secure Boot Certification Authority, Microsoft asked BIOS (UEFI) developers and manufacturers to include their certificates, which looks 100% logical to me. The fact that Linux distributions do not have such power is unfortunate, but it is not Microsoft’s fault at all.
What can we do?
Given its strong ties with Intel, AMD and others, maybe the Linux Foundation could start a task force and a “Temporary Secure Boot Certification Authority” to deal with UEFI BIOS manufacturers and developers.
This task force and TSBCA would act as a proxy for minorities such as Linux, BSD, etc distributions.
I am convinced this is our best chance to get something done in a reasonable amount of time.
Complaining will not get us anything. Screaming at Microsoft will not get us anything. We need to propose solutions.
Wait! Non-Microsoft certificates? Why?
In addition to the missing Secure Boot Certification Authority, there is a second problem apparently nobody is talking about: what is the advantage mainboard manufacturers get from including non-Microsoft certificates?
For instance: why would Gigabyte (or any other mainboard manufacturer) include the certificate for, say, Haiku?
The benefit for Gigabyte would be negligible and if someone with ill-intentions gets Haiku’s certificate, that piece of malware will be installable on all Gigabyte’s mainboards.This would lead to manufacturer-targetted malware, which would be fatal to Gigabyte: “oh, want to be immune to the-grandchild-of-Stuxnet? Buy (a computer with) an MSI mainboard, which does not include Haiku’s certificate”
Given that 99% of desktops and laptops only run Windows, the result of this (yet unresolved) problem would be that manufacturers will only install Microsoft certificates, therefore they would be immune to malware signed with a Slackware certificate in the wild.
If we are lucky, mainboard manufacturers will give us an utility to install more certificates under your own risk.
The solution to the first problem looks easy to me. The solution to the second looks much more worrying to me.
May I recall that GRUB’s boot images are not generated by the distributor, but by GRUB itself each user’s system, in order to include the specific drivers required to access to the file system where GRUB modules are installed?
Thus, the signing key would have to be accessible, not to the distributor, but to the user himself. Anyway, even if the distributor were able to generate and sign generic GRUB images, which would not match GRUB’s usual practices and would certainly restrict the possible customization of installation, that would be completely opposed to the principles of free software since the user would not be able to use modified versions of his own.
In fact, Secure Boot is a specific kind of trusted computing. If the user is in control, that is, if he is able to have his own signing key, so good, but if the usable key is in the hands of some privileged organizations, this become tracherous computing.
Many people, especially enterprise customers, do not modify GRUB images. There is no support for custom kernels.
? Huh? I’m confused what you mean by “no custom kernels in Grub”, because I’ve been booting custom-built kernels via Grub for many years — on both “Grub Legacy” (Grub 1) and Grub2.
Perhaps you mean something relating to something only internal to Grub?
Having a central CA ins’t going to work: you will still be unable to boot your own kernel/bootloader and Debian will also be unbootable as having a private key that derivatives cannot use is against the DFSG. Matthew reported about a proposed solution that will allow for the key to be installed by booting from a special external drive and that will cleanly solve the problem without affecting users’ freedom: http://mjg59.dreamwidth.org/6503.html
I can see the good intentions behind this; eliminating malware is a swell cause. But this feels like another step in a pointless cat-and-mouse game that Microsoft seems to enjoy (and I don’t mean the mouse is Linux). They create a stumbling block for malware, which happens to be an inconvenience also to perfectly valid software groups, and then the malware creators get around the blockade anyway and Microsoft gets pwned…again.
We have ways of authenticating “trusted” software already. We can’t get people to use perform md5sums and gpg key checks, much less to just use common sense and NOT install the spyware app that promises them the world. Do you really think locking down EFI is going to improve anything? Of course it isn’t.
Microsoft should spend time addressing other ways of securing their systems, and a lot less on placing temporary locks on hardware.
If the UEFI system is broken, maybe the corporate giant that is Microsoft should step forward and fix it.
I agree with klaatu. Microsoft is only masking the symptoms with UEFI instead of addressing the cause. Harden the OS itself and then you won’t need these type of maneuvers.
What about source based distributions like Exherbo, Gentoo, … ? Their users compile the whole system by themselfes and thus need access to the private key (that cannot be public if you want to gain any security).
> If we are lucky, mainboard manufacturers will give us an utility to install more certificates under your own risk.
This is the only solution I see. Let the user specify the certificates (maybe his own) he wants to accept. I do not care if Microsoft’s certificate is one of the few that come preinstalled to bios’ flash if I can easily add further certificates (from usb stick, …).
If a generic UEFI certificate loading mechanism is provided, then Linux distributions could add the certificate during installation.
In order to boot the first time, either Secure Boot is disabled, or a signed “universal boot loader” would be needed.
Glad you’ve taken the solutions standpoint!
Instead of going for the “look how Microsoft is trying to do …”
it’s much better to step up and ask: “Hey guys, you’re doing awesome stuff there, how can we join?”
That that lead us to much better results! 🙂
How, I don’t know (not an expert there), that’s something to be investigated by being open.
Awesome stuff? Modifying hardware so that the purchaser can not use it as they desire is awesome stuff? There is a reason that many of us despise Microsoft and one of the best reasons to despise them is their constant efforts to implement things that restrict the rights of their customers. That is true whether they do it alone or in conjunction with hardware manufacturers that they have coerced.
You do realize UEFI was created by Intel, not Microsoft, and there are 11 members in the organization developing UEFI, do you?
No, you don’t
You do realize that Microsoft is a convicted monopolist, right? :-/
The fact that 11 companies are invovled in the UEFI spec has nothing to do with *Microsoft’s* spec on what they’ll accept concerning their “Windows 8” sticker in relation to UEFI.
Hey Francis: just sayin. No need to explode for that.
You haven’t watched Microsoft closely as of last.
They are masters in bending and mis-using standard bodies and processes to boost their market position. OOXML (which I prefer to call MOOXML, for obvious reasons) ist just the most egregious case we had. There are lots of corpses along that lane (WebDAV among others).
BTW — Microsoft ain’t the only one. The SQL “standards” process is another casualty of corporate greed (MS playing an important role there, but there are others…).
So constructive — yes. But it doesn’t help being naïve.
Interesting point about Grub. However, my new laptop has this wonderful ‘feature’ I found out after struggling to get LiveCD’s of openSUSE and Ubuntu going (and openSUSE install DVD). The Ubuntu one would get into grub and after I chose an option, nothing would happen. openSUSE would start loading the kernel I think and after some dots appeared, nothing happened anymore. Lucky for me, there is a BIOS switch and then the LiveCD’s (and install DVD) would boot without a hitch.
If the UEFI system is broken, maybe the corporate giant that is Microsoft should step forward and fix it.
Microsoft is only one of the eleven members of the UEFI Forum:
http://www.uefi.org/about/
Instead of complaining a posteriori, the FSF and/or Linux Foundation should step forward and join the UEFI Foroum (and any other organization that could affect the future of FLOSS).
I think it is fair to put some blame on Microsoft, because they are leading us into this mess, and they are in a position to fix this.
They led us into this by requiring secure boot to meet the designed for program.
They could fix this by requiring users to have control over secure boot to meet the designed for program
Fortunatly, matthew garrett presented an elgant solution to allow to add keys without hurdle or compromising security:
http://mjg59.dreamwidth.org/6503.html
I hope such a solution is implemented.
Wait a minute — you’re suggesting *Verisign* be the authority to certify organizations and to maintain a list of keys for UEFI? That’s crazy. Remember back in the “dark ages” of SSL where Verisign was the only game in town? Nobody wants to go back to those days — those were the days where signed SSL keys were prohibitively expensive, and so the “solution” was to create other CA’s, which then created problems of too many CA’s. Having any one authority be the gatekeeper also causes serious issues of TRUST AGILITY. See:
http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity
The only possible solution here is for UEFI to mandate that the owner of the computer have the “master key” to their own UEFI bootloader. Yes, this means that the machine will be vulnerable to User Error, but there’s NO other way to allow the computer owner to retain their freedom, and so not giving the user this freedom, one way or another, is another attempt at a power grab, and that /*IS*/ Microsoft’s fault for writing their Windows 8 sticker spec such that the user doesn’t get any override choice.
Instructions for the User to install their own key at their own risk is absolutely a fail, too, because very few people will have the technical knowledge on how to do this, leaving them with only one OS choice — and may even void the warranty on the device if one does so, and that would be a serious problem for everybody else.
Regardless of how this is looked at, this is a serious problem, and Microsoft is NOT blameless in how their Windows 8 sticker spec was written concerning UEFI.
— Chris
I’m sorry, but Microsoft is far from being without blame on here. And the best part is, people cite the benefits that this is supposed to create, “oohhh less malware, more secure, trusted system”. The funny thing is, do you realize what percentage of malware *actually* operates on the preboot sequence? It’s virtually none. There simply aren’t any. Will this stop rootkits? haha, definitely not. They’ll still be there in the massive heard that they are.
That’s the thing I don’t understand, it doesn’t significantly benefit *anyone* or *anything*. Does it stop foreign device drivers? No. Does it stop kernel rootkits? No. Does it stop userspace rootkits? No.
Okay, so what does it stop? The only thing it can stop are bios-based rootkits or bootkits. All of which are virtually non-existent. Really. There’s *such* a small amount of them that you have to go out of your way to even find one, let alone get it on your system.
All in all it sounds exactly like another attempt towards the world of Big Brother, and this can only hinder the freedom of genuine customers and their hacking curiousity (read: *nix).
It’s like the GRUB developers themselves have said, UEFI/EFI doesn’t do anything useful, all it does is promote DRM and the restriction of what you would have otherwise “owned”.
To me it feels like yet another way Microsoft and friends are saving the day, one closed-doors protocol at a time, one, one step at a time.
“Okay, so what does it stop? The only thing it can stop are bios-based rootkits or bootkits. All of which are virtually non-existent. Really. There’s *such* a small amount of them that you have to go out of your way to even find one, let alone get it on your system.”
You mean like Suxnet? Or the Sony BMG rootkit?
They’re probably less common, but that doesn’t mean they aren’t a serious problem anymore. The main reason they’re less popular today is that their code is more tied to hardware than malware written to run on top of an OS does, so the OS viruses “have a bigger audience” in terms of the hardware they’ll operate on.
But get infected with one and you end up with a much more hidden and deeper infection than you’ll know what to do with. Some of the more popular boot sector virus/trojan programs encrypt hard disks and will decrypt them only after a ransom has been paid. One name given to this is “RansomWare”:
http://blog.fortinet.com/details-of-the-seftad-ransomware-boot-sector-infection/
Turn on PC
Press DEL on “BIOS Splash”
Search “Boot Secure”
Check Off option
Save Changes & Exit
Well Done! You dont have any problem to boot anything 😀
I hope it’s that simple.
“The certificate that signs those binaries needs to be installed in the UEFI BIOS”
UEFI ain’t BIOS.
BIOS and UEFI are totally different technologies.
UEFI is development of EFI what was Intel own idea to replace PC’s original BIOS.
UEFI ain’t even compatible with EFI and neither one are compatible with BIOS.
There is huge problem in the future as well. (GRUB and Linux have supported EFI/UEFI from the beginning as Linux was the operating system what was used to develop that technology)
The UEFI security features are not needed. It will not save people from malware.
The UEFI security is there only the secure two things. A bootloader and operating system. It does not touch at all to any other software.
And while 0.001% of the malware is already targeting bootloader or operating system, we do not gain any extra protection from UEFI security features. Only harm and usability problems and vendor lock-ins.
What most people do not understand, is that GRUB is bootloader, it only job to exist is to be loaded after motherboard BIOS or (U)EFI and then allow user to choose what operating system image will be loaded. Then it reads the operating system image from the mass storage and executes it.
After that, operating system takes control. It does self check, it does hardware check and then it starts executing system processes by scripts or other configs.
What most people does not know either, is that Linux kernel is whole operating system. There ain’t two different things like “Linux” and “Linux kernel”. They are one and same thing. Linux ain’t microkernel, it is a monolithic kernel == operating system.
How many times you have heard that Linux have been infected, reading after news that it was just some software in user space? Yeah…. there are no malware for Linux operating system, there are some malware for open source software on Unix systems (mostly scripts or other what you need to install and execute by yourself).
Not even Microsoft own NT operating system have infections. Really, no one wants to spend months or years to write rootkit (only malware what attacks against operating system) as it is very hard. Actually only some big corporations have done it, like Sony with their CD DRM program. But crackers writing rootkits? Ha! Updated Linux distribution is such moving target that it is easier to hit with iceberg to a ship than getting rootkit spreading a wild.
UEFI ain’t BIOS.
BIOS and UEFI are totally different technologies.
I know. But saying “UEFI BIOS” makes it easier to understand.
The rest of your comment is bullshit: there are rootkits for Windows, Linux and even Mac. Secure Boot, if used as designed, will make it more difficult to install malware.
But you miss the point, it’s not going to be used the right way. The best we can hope for is a half hearted implementation like TPM
Last time I checked the BIOS on my 2010 laptop still had the A20-Gate option to be compatible with DOS applications that assumed that addresses will wrap after 1MB. Any mainboard that doesn’t include a way to disable the secure boot feature will be incompatible with every OS that was not signed. This includes all previous versions of Windows. Enterprises are just now making the upgrade to Win7 from WinXP. So, Win7 will probably around for as long as XP has been (10 years and counting). It’s a safe bet to assume, that mainboards will keep WinXP/Win7 compatibility at least that long.
We have ways of authenticating “trusted” software already. We can’t get people to use perform md5sums and gpg key checks
Have you ever heard of DNS poisoning, IP proxies, VPN tunnels, etc? People are using that all the time for direct downloads, watching TV for free (BBC iPlayer anyone?), etc
That invalidates md5sums and gpg key checks because the checksum itself is already faked.
Secure Boot is essentially GPG signing the boot image, by the way.
You missed a third problem, which matters even more for the reputation of Linux: the proposed solution leaves the Linux Foundation (or whoever serves as the signing authority) responsible for who they delegate that authority to. Any distribution that the Linux Foundation hands a key to could potentially create malware, and that will generate huge negative PR for that signing authority. Anyone wishing to create malware can simply pose as a Linux distribution; and if the Linux Foundation starts limiting who they delegate signing authority to, that causes problems of its own.
Beyond that, just a single signed copy of GRUB or any other programmable Linux bootloader would allow malware to piggyback on it, since GRUB will boot anything its configuration tells it to.
Enjoy your locked down boring world with training wheels attached to everything.
I want to boot into an OS written in self-modifying assembly that’s different every time you boot it.
awww i want one
I do see bad intentions or stupidity. Why do they do it like that? A centralised system, that is really stupid, some certificate may get leaked and then it is useless. Why don’t they simply allow checking check sums defined by the user? That way nobody would have to trust the authority handling the certificates, and everybody with any system would get warned about manipulated kernel images.
Requiring signed binaries to boot is inherently incompatible with Free Software. A central point of Free Software is that users can modify their software at will. Requiring a central authority to sign their software means they effectively no longer can do this. Thus, we CANNOT embrace this “standard”. There can be NO solution which includes this “standard” under any form.
It’s not good enough to have an official organization that would let the big distros sign their binaries. This would cut out independent developers. The person or organization that owns the machine needs to be able to control the keys, and choose which keys are honored. Further, if a machine is intended for dedicated use with a stripped-down Linux version, it should be possible for the owner to configure the machine not to accept Microsoft’s keys. Giving a convicted monopolist a privileged position, or worse, allowing a world to be created where mass-market machines boot only Windows, would be the worst possible outcome, but cutting a deal saying that only Microsoft, Red Hat, and Canonical have recognized keys by default would be just as bad.
One possibility to get the benefits of secure boot without the harm is for machines to have a mode that allows the owner to add or remove arbitrary keys in a secure way (possibly by flipping a hardware switch, so that remote attackers could not mess with keys).
Secure Boot is a valid solution for stopping certain kinds of malware. There is indeed a fundamental incompatibility with the first principles of Free Software (and, in non-US countries, with the basic principles of national security). So, to boot Free operating systems, we would just need different hardware or a switch. The real problems that would arise if this is implemented:
1) How to convince manufacturers to produce boards with comparable specs in both secure and non-secure classes?
2) How to convince shops to sell them?
3) How to inform the customers where to get this kind of hardware?
GRUB2 is licensed GPL3+. That means, that if a particular key is needed to get the binary running on a target system, that key becomes part of the source. Therefore it is only legal to distribute GRUB2 signed for Secure Boot if the user can install their own key in the BIOS. Which I believe is the only viable solution anyway. There needs to be a way for installation media to provide a key and for user to accept and install that key.
And I also think that including only particular (probably Microsoft) key with no provision for installing other keys would be violation of European competition law and given the history of cases against Microsoft, I can imagine with some lobbying the solution would be enforceable at least in Europe (and it’s not likely anybody will bother removing the option for the rest of the world if they have to provide it somewhere).
I doubt you could make this one sticking on MS. It’s the OEMs that build the hardware and provide the firmware. If they don’t include trusted keys from somebody besides MS that’s not MS’s fault.
World doesn’t need UEFI at all. Locking hardware is the way no nowhere. Doesn’t UEFI means that if a new company founded, ie in 2012, won’t be able to run its software in any computer build before because its certificates are not in the UEFI BIOS?
Who and how is going to update the certificates in the my UEFI BIOS?
Just don’t buy a piece of hardware with that hellish technology.
Preboot malware, as has been mentioned above, is very uncommon. I simply can’t believe that they would go through the trouble of implementing this just to protect users from an essentially non-existent threat.
The real reason they are doing this is to lock out competition. There just isn’t any other rational reason to be doing this. I’m guessing that Microsoft pushed for this by proxy.
I’m not interested in owning a computer that dictates what I can and cannot do with it. If this garbage ever does go mainstream then I’ll be making sure that it can be disabled before I buy anything.
“The real reason they are doing this is to lock out competition.”
The real reason is simpler than this : to stop piracy. Linux users are a minority compared to the huge numbers of people who use illegal copies of Windows, and the point is to get them to pay for it.
We may lose our freedoms to use alternative os, or being able to tweak and compile our own, just so that Microsoft could get even more money from the pest that are people who crack windows. That’s right.
I am sad that you have bought into Microsoft’s view on this.
“Given that 99% of desktops and laptops only run Windows”
Um. No, that is not true at all. It seems you have forgotten Apple, and while it’s hard to measure Linux desktop and laptop penetration, it is certainly more than 1%. Anyway, as so many commenters have pointed out, the problem is Microsoft’s utter inability to write secure software, and that their entire business model is bullying, lockin, protection rackets, and locking out the competition no matter how much scorched earth it takes. I absolutely do not believe that locking down UEFI is in any way necessary– not until you present some actual data proving there is a threat of significant size to justify building an entire CA infrastructure, and requiring computer OWNERS– yes, we OWN our computers– to jump through all kinds of hoops just to keep Microsoft happy. This is just another raised middle finger from Microsoft.
The main reason for this “secure boot” feature is to stop people circumventing windows authentication/activation. It would be better if MS would just admit it. It would probably be cheaper for all (and more profit for MS) if the would just lower the price for W7 to 40USD (and only have two versions, server/WS).
Less piracy, more money for MS and no more need for “secure boot” everybody is happy!
Linux has gone from the toolshed to a lemonade stand who is to say it won’t become the next Windows. Better to just transition to FreeBSD.