[personal profile] mjg59
I wrote about the technical details of supporting the UEFI secure boot specification with Linux. Despite me pretty clearly saying that this was ignoring issues of licensing and key distribution and the like, people are now using it to claim that Linux could support secure boot with minimal effort. In a sense, they're right. The technical implementation details are fairly straightforward. But they're not the difficult bit.

Secure boot requires that all code that can touch hardware be trusted

Right now, if you can run unstrusted code before the OS then you can subvert the OS. Secure boot gives you a mechanism for making sure you only run trusted code, which protects against that. So your UEFI drivers have to be signed, your bootloader has to be signed, and your bootloader must only load a signed kernel. If you've only booted trusted code then you know that your OS is safe. But, unlike trusted boot, secure boot provides no way for you to know that only trusted code was executed. That has to be ensured by OS policy.

This doesn't sound like too much of a problem. But it is. Imagine we have a signed Linux bootloader and a signed Linux kernel, and that these signatures are made with a globally trusted key. These will boot on any hardware using secure boot. Now imagine that an attacker writes a kernel module that sets up a fake UEFI environment, stops the kernel from running code and then executes the Windows bootloader - kind of like kexec, but a little more fiddly. The Windows bootloader believes that it's performing a secure boot, but in fact everything that it believes is trustworthy is the attacker's fake UEFI code. The user's encryption passphrase is logged, the Windows kernel is modified to hide the Linux code and despite everything looking fine your credit card details are on their way to China. In this scenario, the signed Linux kernel is simply used as a malware loader. The only sign that anything is wrong is that boot will be slightly slowed down.

Signing the kernel isn't enough. Signed Linux kernels must refuse to load any unsigned kernel modules. Virtualbox on Linux? Dead. Nvidia binary driver on Linux? Dead. All out of tree kernel modules? Utterly, utterly dead. Building an updated driver locally? Not going to happen. That's going to make some people fairly unhappy.

(The same applies to Windows, of course. Windows 7 allows you to disable driver integrity checks. Windows 8 will have to forbid that when the system's using secure boot)


GPLv3 has various requirements for signing keys to be available. Microsoft's new requirement that systems support the installation of user keys would let users boot their own modified bootloaders, so that may end up being sufficient to satisfy the license. But we're then beholden on Microsoft - if they remove that requirement then users lose that freedom, and suddenly we're in an awkward licensing situation. There are ongoing conversations about exactly what we're able to do here, but it's not a solved problem.

Key distribution

The UEFI spec doesn't describe or mandate a central certifying authority. Microsoft require that everyone carry their key. We could generate our own, but we have much less sway with vendors. There's no way to guarantee that all hardware vendors will generate our key. And, obviously, if we generate a key, we can't just hand the private half out to others. That means that it becomes impossible for people to produce derivative versions of Linux distributions without getting their own key. The kind of identity verification that would be required for getting such a key is likely to be expensive, and also fairly likely to require that the distribution have a legally registered company in order to facilitate the identity verification. Think Extended Validation certificates, not Startssl Free. Hobbyist Linux distributions will be a thing of the past.

Doesn't custom mode fix this?

Microsoft's certification requirements now state that all systems must support a custom mode, implying that it will be possible for a user to install their own keys. Linux vendors would then be able to ship with their own keys on the install media and impose their own policies. Everyone's happy. It's not really good enough, though. People have spent incredible amounts of time and effort making it easy to install Linux by doing little more than putting a CD in a drive. Asking them to go into the firmware and reconfigure things adds an extra barrier that restricts the ability to install Linux to more technically skilled users. And it's even worse than that. This is the full description of the requirement for custom mode:
  1. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
  2. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with Secure Boot turned off.
  3. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.

There's a few things missing from this, namely:
  • Any description of the UI. It's effectively impossible to document Linux installation when the first step becomes (a) complicated and (b) vendor specific. Vendors are using the UEFI transition to differentiate themselves by coming up with their own unique firmware interfaces. Custom mode is going to look different everywhere.
  • Any description of the key format. A raw binary representation of the key? An EFI_SIGNATURE_DATA struct? A base64 encoding of one, further protected with ROT13? We just don't know.
  • Any way to use custom mode for unattended installs. It's a firmware interface that requires a physically present user. Want to install a few thousand machines over the network? This isn't a scalable approach
  • …and this one's nitpicking, but there's not actually any requirement that the user be able to add keys - a vendor could conform to this language by only letting users delete keys. This is actually ok as long as the user deletes Pk, because then we'll effectively be back in setup mode and can install our own keys from the installer, but it still results in some practical problems

So no, custom mode doesn't make everything ok. Custom mode with a mandated UI and a documented key format would be much closer, but it wouldn't solve the problem of unattended automated installs.


We can write the code required to support secure boot on Linux in a minimal amount of time - in fact, most of it's now done. But significant practical problems remain, and so far we have no workable solutions for any of them.
Page 1 of 2 << [1] [2] >>


Date: 2012-01-18 02:39 am (UTC)
From: (Anonymous)
2 interesting points:

windows8-hardware-cert-requirements-system.pdf (http://msdn.microsoft.com/en-us/library/windows/hardware/hh748200.aspx)
direct link (http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf)

MANDATORY: Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.

Disabling Secure MUST NOT be possible on ARM systems.

i wonder, whether disabling a user to disable SecureBoot is something European Commission would like to have a word with M$ about
From: [identity profile] stuartward.wordpress.com
The whole point of having windows available on ARM was so that us Linux heads could have arm based laptops with the long battery life and lots of cores (I've heard of 256 core boards). It will be very disappointing not to be able to run on these ARM based systems.

Re: windows8-hardware-cert-requirements-system.pdf

From: (Anonymous) - Date: 2012-01-25 08:22 am (UTC) - Expand

Re: windows8-hardware-cert-requirements-system.pdf

From: (Anonymous) - Date: 2012-01-18 04:31 pm (UTC) - Expand

Re: windows8-hardware-cert-requirements-system.pdf

From: (Anonymous) - Date: 2012-06-06 09:31 pm (UTC) - Expand

Re: windows8-hardware-cert-requirements-system.pdf

From: (Anonymous) - Date: 2012-06-22 09:07 pm (UTC) - Expand

Can you say, "UEFI"?

From: (Anonymous) - Date: 2012-08-31 01:10 am (UTC) - Expand

Generating keys

Date: 2012-01-18 04:22 am (UTC)
From: (Anonymous)
One solution to the problem regarding keys is to allow the user to generate their own keys (which would effectively also remove the problem with getting keys for small/hobby distros). This still doesn't solve the problem with installing them though.


Date: 2012-01-18 04:34 am (UTC)
From: [personal profile] dmarti
Hey, we have an excuse to have Linux installfests again. Come on down--It'll be like 1998 except I'll have less hair.

....pointless banter

Date: 2012-01-18 04:57 am (UTC)
From: (Anonymous)
The message is clear. You want power over secure boot? Buy Intel!

Please, explain. better

Date: 2012-01-18 07:14 am (UTC)
From: (Anonymous)
I didn't understood properly,
Isn't the kernel allowed to execute untrusted code (say - nvidia blob) because of a technical UEFI reason,
or will it refuse to execute by choice (read: stay into UEFI domain/respect what uefi secure boot should be used about?)

Re: Please, explain. better

Date: 2012-01-19 12:36 am (UTC)
From: (Anonymous)
IF there was to be a particular instance of a compiled Linux kernel that was signed by a globally trusted key, then THAT compiled kernel would necessarily have to be crafted so that it was not able to execute untrusted kernel code. This is simply because if it DID run any old code in kernel mode, then those in charge of the globally trusted key would never sign it, since the existence of such a kernel would undermine the entire system.

The proper take-away from this is that such a signed Linux kernel won't exist.

Note that this also implies that if a bug is ever found in a signed Windows kernel that allows arbitrary code execution in kernel space, then the security of the whole system will also be undermined. It doesn't matte if Microsoft subsequently patches that bug; once the signed-but-buggy kernel is out in the wild then it can be used to build a signed malware bootloader.
From: (Anonymous)
Hi Matthew, I have been thinking about this issue a lot and the only solution I have found that is both good for Linux and Windows would be to ask for the UEFI admin password when attempting to boot from an untrusted kernel. Once the password has been verified, the kernel could be automatically signed by the TPM and the password would never be asked again. That should be secure since the UEFI code is signed (no fake window here) and an already-trusted OS is unlikely to suddenly ask for the password by copying the password window's style. I personally would like something like this to happen instead of the key nightmare we are going to see but I understand that companies would like to be able to sign one kernel and distribute it to all their client instead of having to write the UEFI admin password every time an update occurs. Is there any silly case I forgot to take into account? MùPùF (sorry, no account)
From: (Anonymous)
This doesn't really help; now you're requireing people to know a password for their firmware -- something most people don't have as it is. Heck, they don't even have a password for the users on the desktop operating system (i.e. windows). This doesn't make the problem with increasing the installation complexity go away; it just changes it.

Server vs. Client

Date: 2012-01-18 09:11 am (UTC)
From: (Anonymous)
Assuming I am reading the document correctly a client (desktop / notebook) is only required to have an ON/OFF switch for secure boot. The whole key configuration stuff is only mandated for servers.

Too many issues

Date: 2012-01-18 11:23 am (UTC)
From: [identity profile] poisonbit.wordpress.com
If someone could execute "bad code" at my boot time, I should be more worried about "why"? the fail must be in other subsystem of my system.

From the security issues I've seen in servers and desktops in more than 10 years, daily, I can say I've not seen too much issues, that could have been avoided by this technology in comparison to other issues.

I'm more worried about bad fonts in HTML5 or PDF, than in the boot stage of my home desktop.

To much issues, just to put other brake on Linux, they do not mean security of the final user at all.

Re: Too many issues

Date: 2012-01-18 08:21 pm (UTC)
From: (Anonymous)
I'm not sure the main target of secure boot is servers and desktops.

David Kemp

Date: 2012-01-18 12:36 pm (UTC)
From: (Anonymous)
Please use semantically correct markup in your posts -> brs are for line breaks, p(aragraphs) are for paragraphs.

Date: 2012-01-18 02:32 pm (UTC)
From: (Anonymous)
You have forgotten ARM. Custom mode is forbidden on ARM, and maybe in the future on PC, too. No one should be happy about this.

Date: 2012-01-18 03:11 pm (UTC)
From: (Anonymous)
Exactly. ARM is starting to target servers and netbooks (smartbooks), and if that trend continues it might not be long before notebooks start using ARM processors too.

Personally I can't imagine server machines which won't run linux from being too popular, so MS may have a problem (or split the hardware market) there. But in other cases...

From my point of view I'm not much fussed about whether linux could support secure boot, only about whether I can still install the kernel and drivers I want to use.

(no subject)

From: (Anonymous) - Date: 2012-01-19 12:05 pm (UTC) - Expand

Date: 2012-01-18 03:32 pm (UTC)
From: (Anonymous)
Is it right that Custom Mode is forbidden on PCs with Connected Standby, too? If yes, one problem more.

What about using BIOS module?

Date: 2012-01-18 05:09 pm (UTC)
From: (Anonymous)
I am wondering if this UEFI secure boot is in any way enforced for people using a BIOS compatibility module and installing an OS that is not natively UEFI aware.

unsigned kernel modules

Date: 2012-01-18 06:55 pm (UTC)
From: (Anonymous)
"Signed Linux kernels must refuse to load any unsigned kernel modules."

Who would emplace & enforce this constraint?

Re: unsigned kernel modules

Date: 2012-01-18 11:31 pm (UTC)
From: (Anonymous)
"your credit card details will be on their way to China." Only people in China steal credit card details??? Xenophobia shows through, no matter what you write.

Re: unsigned kernel modules

From: (Anonymous) - Date: 2012-01-19 08:04 am (UTC) - Expand

Re: unsigned kernel modules

From: (Anonymous) - Date: 2012-01-19 08:06 am (UTC) - Expand
From: [identity profile] linuxpixies.blogspot.com
Want to buy a Linux device ? Good, buy it from an OEM which does not sell Windows.
There are not many. That is true. But still, there are enough, and Linux is a great OS, so you should support businesses who support Linux. Hence, buying OEM equipment which comes with M$ products is your Freedom, but it not supporting Freedom!
More on this on my Blogpost here http://linuxpixies.blogspot.com/2012/01/uefi-secure-booting-is-good-for-linux.html
From: (Anonymous)
There are many? Last I checked, there are many only for those who live in the G8.

Re: UEFI Secure booting is actually a good thing for linux

From: (Anonymous) - Date: 2012-01-19 08:07 pm (UTC) - Expand

Re: UEFI Secure booting is actually a good thing for linux

From: (Anonymous) - Date: 2012-01-23 05:19 am (UTC) - Expand

Date: 2012-01-19 05:43 pm (UTC)
heliumbreath: (Default)
From: [personal profile] heliumbreath
Asking vendors to set up their own user interfaces will rapidly lead to agreement that at least N-1 of them are crap.

Configuring Keys

Date: 2012-01-19 08:54 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawkgWMHXDsANXvdhDdhRy23BZBVwGl2Kprg
If you have got a few thousand new computers you will need to physically install them and configuration can be done at that time. Alternatively the supplier can supply a private key or signed instruction to install a new public key.

There should be a conditionally enabled APIs for installing keys.

Date: 2012-01-23 05:36 am (UTC)
From: (Anonymous)
Even if they manage to distribute the keys in a manner that generates trust, without appropriate transparency, how do I know that the vendors are protecting their private key data?

Not to mention the build system.

It's only a matter of time before a rogue operating system is released using the misappropriated key data of an unfortunate OEM vendor. I hear that there are still some nation states with enough cash to fund this sort of subversive activity.

Ps.BOFH, I received an error while logging in using Google Appspot OpenID

ARM disabling custom boots ?

Date: 2012-02-13 10:30 pm (UTC)
From: (Anonymous)
I cant see this working out very well for ARM. I'm working on ARM based embedded systems and we use custom Linux kernels for all of them. Why would they shoot themselves in the foot and give up that ability ?

UEFI signing yes sure...

Date: 2012-02-15 06:32 pm (UTC)
From: (Anonymous)
I think the restrictions on ARM will be crushed by the EU here.
I always think the hole thing will be like BlueRay, the key leaks, c´mon, such a big PKI that is used world wide, there will be someone who builds a massive network to crack the key, or someone will leak it..

Anyway, there will be some windows kernel module from some hardware distributor, that is signed and has a bug to allow execution of kernelmode custom code.. There has to be only one simple bug in a whole bunch of code, that breaks the system for all keys out there.

This will happen and it will be used by RootKits and so on, so the whole system is fucked up anyway..

In case of problems?

Date: 2012-02-15 11:33 pm (UTC)
From: (Anonymous)
If I understand in case of my windows were infected by a virus or my windows fails for any reason, I can't restart my computer with another recovery disk except those provided by Microsoft, Right?. But usually laptops don't come with the installation media, right?. So in case of virus I have to go to another healthy system to recover my data. Actually it is more secure or more inconvenient or is to secure technically the cash flow from my pocket to M$?.

What would happen if a virus could get with the Windows keys which is more likely than: "Now imagine that an attacker writes a kernel module that sets up a fake UEFI environment, stops the kernel from running code and then executes the Windows bootloader - kind of like exec, but a little more fiddly. The Windows bootloader believes that it's performing a secure boot, but in fact everything that it believes is trustworthy is the attacker's fake UEFI code"; even thought my boot safe computer the key could be compromised?. If that theory not true? if is the case, then we have the same security than we have now and again is for secure the cashflow from... Otherwise and at the end is not my decision as hardware purchaser to decide what to do with it and what OS I would like to install and what risks I want or can assume?. Is more dangerous to drink Coca-Cola or drive a car or even go to work than use a computer (My life could be threatened in some cases and is more important than my HD information anyway).

Definitively I must to buy a computer with coreboot or not big-brand computer.

Date: 2012-02-16 06:31 am (UTC)
From: (Anonymous)
A few things I'm wondering after reading this article, maybe someone could clarify for me...

Kernel modules - If I'm understanding this part correctly, the issue is that loading unsigned modules would be a security risk? If that's the case, couldn't Linux simply whitelist some necessary unsigned modules, such as nvidia and vmware, while refusing to load any others?

Key distribution - What exactly differentiates, say, Mint from Ubuntu, such that it would need a different key? At what point has a distro diverged to where it needs to have its own key? Is there some way a single "GNU Linux OS" key could be registered for all distributions?

Custom mode - Would it be unfair to assume that organizations planning to install Linux across thousands of workstations would choose to only buy hardware that allows for unattended installs? The market would seem to dictate this, even if the UEFI spec doesn't.

Delegate UEFI for appliances only

Date: 2012-03-17 09:09 pm (UTC)
From: (Anonymous)
When development or maintenance tasks become prohibitively expensive in time, software development, certificates or knowledge requirements, there will be a move to alternate solutions to UEFI. In the meantime I can see the day that a cheap discard-able UEFI based appliance, not upgradable, would be used for secure connections. Want to connect to the bank, use the appliance, want to transfer data files, create a md5sum, encrypt the file and include the md5sum in the encrypted file. Use a different appliance for the file transfer.

For a secure operating system, to respect UEFI security when requiring a system patch or upgrade the vendor must always include the entire system. The certificate applies to the whole deliverable, and you should not accept patches. Patch ability makes your system half safe and opens the door to security breeches.

Imagine the hardware vendor costs if he wants his logo within a UEFI bios for his new tablet, net-book, server, or whatever. His costs will soar as replacing one chip on the mother board with one from another vendor may change the motherboard checksum.

The software developer, the student in a computer science class, the applications seller, the embedded controller vendor, are their efforts and products going to fall under the UEFI requirements?

UEFI is doomed to fail, and will be replaced by something better.

A (maybe stupid) Question

Date: 2012-04-23 10:17 pm (UTC)
From: (Anonymous)
You claim that the entire process, bootloader, kernel, AND kernel modules must be signed. Does not the signing need to extend to all executables run in that environment as well? The OS will load an executable, and that executable can check if it is running in a Secure Boot chain. But, for that fact to have validity, the executable also requires signing. Otherwise, what prevents that executable from performing system level emulation, or interposition?

The only real solution (in my opinion) is TPM, or MAC security. If MAC security is implemented by the OS, then drivers would not need to be signed (presuming that the purpose is to prevent malware). The MAC security can prevent user applications from modifying any part of the OS. If neither MAC, nor adding executables to the chain is implemented, malware could then simply interpose in an OS (being part of the executable, rather than part of the OS -- classic virus strategy).

If the executable were protected by the OS, how does application installation work? I don't know the mechanism for updates here (Microsoft would have to have a Secure Apps Store for Windows 8 to make this part work).

I would expect that (at the least) any program that can generate an executable would need signing, and the OS mechanism for allowing an executable (in Linux terms, chmod and the OS loader) would require signing as well.

Where does UEFI Secure Boot responsibility actually end?

Sorry for the question -- I haven't read the UEFI specification, and this may be covered in there.

I don't have time to read replies -- please email at fred (dot) weigel (at) treklogic (dot) com


Date: 2012-06-07 09:54 am (UTC)
From: (Anonymous)
'your credit card details are on their way to China'.

Gosh, for a moment I was worried they could go to the US. I'd rather prefer Chinese bank robbers.

Ok, so what should I ask my hardware vendor?

Date: 2012-06-22 08:04 pm (UTC)
From: (Anonymous)
So, lets say I'm in the market for a new PC, and I want to install a custom OS of my own devising, what question do I need to ask my HW vendor to make sure I don't wind up with a machine that is DRM'd into uselessness?
Page 1 of 2 << [1] [2] >>


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags