[personal profile] mjg59
It's fairly straightforward to boot a UEFI Secure Boot system using something like Shim or the Linux Foundation's loader, and for distributions using either the LF loader or the generic version of Shim that's pretty much all you need to care about. The physically-present end user has had to explicitly install new keys or hashes, and that means that you no longer need to care about Microsoft's security policies or (assuming there's no exploitable flaws in the bootloader itself) fear any kind of revocation.

But what about if you're a distribution that cares about booting without the user having to install keys? There's several reasons to want that (convenience for naive users, ability to netboot, that kind of thing), but it has the downside that your system can now be used as an attack vector against other operating systems. Do you care about that? It depends how you weigh the risks. First, someone would have to use your system to attack another. Second, Microsoft would have to care enough to revoke your signature. The first hasn't happened yet, so we have no real idea how likely the second is. However, it doesn't seem awfully unlikely that Microsoft would be willing to revoke a distribution signature if that distribution were being used to attack Windows.

How do you avoid that scenario? There's various bits of security work you need to do, but one of them is to require that all your kernel modules be signed. That's easy for the modules in the distribution, since you just sign them all before shipping them. But how about third party modules? There's three main options here:

  1. Don't support third party modules on Secure Boot systems
  2. Have the distribution sign the modules
  3. Have the vendor sign the modules

The first option is easy, but not likely to please users. Or hardware vendors. Not ideal.

The second option is irritating for a bunch of reasons, and a pretty significant one is license-related. If you sign a module, does that mean you're endorsing it in some way? Does signing the nvidia driver mean that you think there's no license concerns? Even ignoring that, how do you decide whose drivers to sign? We can probably assume that companies like AMD and nvidia are fairly reputable, but how about Honest John's Driver Emporium? Verifying someone's identity is astonishingly expensive to do a good job of yourself, and not hugely cheaper if you farm it out to a third party. It's also irritating for the driver vendor, who needs a separate signature for every distribution they support. So, while possible, this isn't an attractive solution.

The third option pushes the responsibility out to other people, and it's always nice to get other people to do work instead of you. The problem then is deciding whose keys you trust. You can push that off to the user, but it's not the friendliest solution. The alternative is to trust any keys that are signed with a trusted key. But what is a trusted key? Having the distribution sign keys just pushes us back to option (2) - you need to verify everyone's identity, and they need a separate signing key for every distribution they support. In an ideal world, there'd be a key that we already trust and which is owned by someone willing to sign things with it.

The good news is that such a key exists. The bad news is that it's owned by Microsoft.

The recent discussion on LKML was about a patchset that allowed the kernel to install new keys if they were inside a PE/COFF binary signed by a trusted key. It's worth emphasising that this patchset doesn't change the set of keys that the kernel trusts - the kernel trusts keys that are installed in your system firmware, so if your system firmware trusts the Microsoft key then your kernel already trusts the Microsoft key. The reasoning here is pretty straightforward. If your firmware trusts things signed by Microsoft, and if a bad person can get things signed by Microsoft, the bad person can already give you a package containing a backdoored bootloader. Letting them sign kernel modules doesn't alter the power they already have over your system. Microsoft will sign PE/COFF binaries, so a vendor would just have to sign up with Microsoft, pay $99 to Symantec to get their ID verified, wrap their key in a PE/COFF binary and then get it signed by Microsoft. The kernel would see that this object was signed by a trusted key and extract and install the key.

Linus is, to put it mildly, unenthusiastic about this idea. It adds some extra complexity to the kernel in the form of a binary parser that would only be used to load keys from userspace, and the kernel already has an interface for that in the form of X509 certificates. The problem we have is that Microsoft won't sign X509 certificates, and there's no way to turn a PE/COFF signature into an X509 signature. Someone would have to re-sign the keys, which starts getting us back to option (2). One way around this would be to have an automated service that accepts PE/COFF objects, verifies that they're signed by Microsoft, extracts the key, re-signs it with a new private key and spits out an X509 certificate. That avoids having to add any new code to the kernel, but it means that there would have to be someone to run that service and it means that their public key would have to be trusted by the kernel by default.

Who would that third party be? The logical choice might be the Linux Foundation, but since we have members of the Linux Foundation Technical Advisory Board saying that they think module signing is unnecessary and that there's no real risk of revocation, it doesn't seem likely that they'll be enthusiastic. A distribution could do it, but there'd be arguments about putting one distribution in a more privileged position than others. So far, nobody's stood up to do this.

A possible outcome is that the distributions who care about signed modules will all just carry this patchset anyway, and the ones who don't won't. That's probably going to be interpreted by many as giving too much responsibility to Microsoft, but it's worth emphasising that these patches change nothing in that respect - if your firmware trusts Microsoft, you already trust Microsoft. If your firmware doesn't trust Microsoft, these patches will not cause your kernel to trust Microsoft. If you've set up your own chain of trust instead, anything signed by Microsoft will be rejected.

What's next? It wouldn't surprise me too much if nothing happens until someone demonstrates how to use a signed Linux system to attack Windows. Microsoft's response to that will probably determine whether anyone ends up caring.

Date: 2013-02-27 03:28 pm (UTC)
From: [identity profile] pjc50.livejournal.com
What is "attack Windows" in this context?

FSF via wikipedia:

Freedom 0: The freedom to run the program for any purpose.
Freedom 1: The freedom to study how the program works, and change it to make it do what you wish.
Freedom 2: The freedom to redistribute copies so you can help your neighbor.
Freedom 3: The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefit)

I would argue that if the user cannot modify the kernel and run it, or load their own modifications in the normal way, that violates "Freedom 3", and if we want to be really pedantic then preventing an "attack on Windows" violates Freedom 0.

(Admittedly I disagree with this argument when it's made about the Raspberry Pi GPU, but that's the strange world we're now in; a "computer" contains many different processors and state machines, some of which are user accessible and some of which aren't. This particular "secure" business is a software boundary rather than a hardware one; on one side the user can run any program they want, and on the other they can't.)


Date: 2013-02-27 05:29 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawmy3iIBA3q2VxDn8VEhueNRjSoWm79j0J4
Hi Matthew,

What would be so terribly hard about a coalition of large distros outsourcing identity verification to an existing CA? We already trust the CAs to do this verification for a wide range of uses, and their charges for those other uses isn't terribly excessive. Certainly for huge corporations like nvidia and AMD it would be less than a rounding error, especially if they only had to be verified once for many distros. It doesn't seem to me like a Distro Coalition would in any way be endorsing the modules signed this way—all they'd be claiming is "if this is exploited, we can revoke the key", which is clearly true.

I'm sure I must be overlooking something, so what's the problem with this solution?

Attack vector example?

Date: 2013-02-27 06:06 pm (UTC)
From: (Anonymous)
What would be an example of the attack vector against other operating systems enabled by secure boot signing?

Re: Attack vector example?

Date: 2013-02-27 07:16 pm (UTC)
From: [identity profile] kevinkofler.wordpress.com
But the key term there is "on bare metal". Nothing in "Secure" Boot stops the Blue Pill attack.

Re: Attack vector example?

From: (Anonymous) - Date: 2013-02-27 07:42 pm (UTC) - Expand

Re: Attack vector example?

From: [identity profile] kevinkofler.wordpress.com - Date: 2013-03-06 10:40 pm (UTC) - Expand

you can detect when running virtualized

From: (Anonymous) - Date: 2013-02-28 08:22 pm (UTC) - Expand

Re: Attack vector example?

Date: 2013-02-27 09:10 pm (UTC)
From: (Anonymous)
It looks to me that it's what *trusted* boot is for. Encrypt your windows partition with a random key and encrypt that key with a key sealed in your TPM.

So tired...

Date: 2013-02-27 11:14 pm (UTC)
From: (Anonymous)
Reasonably non-naive person here who has used Linux since 1993:

What I want is the ability to buy the hardware I want and install the distribution I want without being bothered to mess around with keys, yada, yada, yada.

What I want is the ability to use Linux and enable Secure Boot if I want to, without messing around with keys, yada, yada, yada.

If we end up in a situation that sees many Linux users running with secure boot disabled, *and* then we see some of those Linux machines being used in successful, widespread, and well-publicized attacks, no distinction will be made between Linux with secure boot enabled and Linux with secure boot disabled. Linux will take the fall in grandiose fashion and be branded as the OS of choice for criminals.

Finally, I cannot even begin to tell you how tired I am of being told, in so many words, that I should just put up with one or another Linux inadequacy or annoyance because we are all one big happy community out to defeat the Microsoft dragon.

secure boot has implications

Date: 2013-02-28 08:26 pm (UTC)
From: (Anonymous)
Linux allows you to do many things (kexec, KVM, etc.) that can be used for nefarious purposes.

In a secure-boot environment you either need to prevent people from doing those things, or else you need to make sure that they do them in a way that preserves the chain of security--which means messing with keys.

On Microsoft systems the problem is simplified--you can't do kexec, period. And if you want to load your own custom modules onto a secure system you need to mess with keys.

Wow, what a lot of dissembling!

Date: 2013-02-28 02:25 am (UTC)
From: (Anonymous)
Still enthusiastic about tailgating Microsoft after having all your theories debunked conclusively by Lins Torvalds?

I guess religion must be something like this.

When are you going do a post about the other changes that need to be made in kernel - hibernation and kexec - in order to satisfy your overlords at Redmond?

Sam Varghese

Re: Wow, what a lot of dissembling!

Date: 2013-02-28 05:55 am (UTC)
From: (Anonymous)
There's plenty available all over the web but if you'd prefer to read my pieces, here are the links:



Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 06:21 am (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 07:17 am (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 08:47 am (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-03-01 03:26 am (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-03-01 06:14 am (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 12:17 pm (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 03:42 pm (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: [personal profile] maco - Date: 2013-02-28 07:16 pm (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 11:24 am (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 12:15 pm (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 04:23 pm (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 04:44 pm (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 08:12 pm (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 10:49 pm (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 10:58 pm (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-02-28 11:02 pm (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-03-01 03:29 am (UTC) - Expand

Re: Wow, what a lot of dissembling!

From: (Anonymous) - Date: 2013-03-01 04:03 pm (UTC) - Expand


From: [identity profile] akuckartz.myopenid.com - Date: 2013-03-02 12:13 pm (UTC) - Expand

Re: Reputation

From: (Anonymous) - Date: 2013-03-02 01:41 pm (UTC) - Expand

isn't the shim already breaking security

Date: 2013-02-28 03:14 am (UTC)
From: (Anonymous)
Didn't I read something from you recently about the shim bypassing secure boot entirely since it can basically run anything? If this is true, then the security of SecureBoot is all theatrics. Microsoft has already signed something that will bypass all their good intentions. If they understand this then security was not really the point of SecureBoot.

Re: isn't the shim already breaking security

Date: 2013-02-28 06:41 pm (UTC)
From: (Anonymous)

I think the physical access bit is where it gets confusing. I've tried to follow this and I'm still confused about how things fit together (so I just disable secure boot).

Excluding ARM because it is configured differently, and focussing on x86 my understanding is:

Physical access is complete control either by:
a) disabling secure boot
b) adding ones own keys
c) having bootable media present at boot time that is signed with a pre-existing key (ie MSFTs)
The only attack secure boot is designed to prevent on x86 is a remotely delivered virus that exploits a vulnerability to reach priviliged mode and tries to modify the kernel to setup a rootkit. Such a virus would not have the requisite signature to be able to inject code or keys into the secure boot infrastructure, and the subsequent boot would fail.

The shim bootloader is not capable of attacking the system without physical access because it only executes and installs keys at boot time and only with physical access. MSFT is happy to sign it because they don't care what happens at boot time with physical access, they care about what happens after boot time and where physical access cannot be demonstrated to the hardware.

Is that a correct characterization?

Date: 2013-02-28 08:49 am (UTC)
From: (Anonymous)
Thanks Matthew for doing this.

I don't know whether or not Linux is about choice. But I really appreciate being able to choose between booting Linux with secure boot enabled or disabled. And your work ensures that that will just work, not just now but also in the future.

A possible 4th solution...

Date: 2013-02-28 11:54 am (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawlCU1zTyt93a3dVM62Sb4a2z7MnZfTnsoY
Rather than having the distributions sign the modules, why not just have them sign one module, the one that lets the kernel read PE/COFF signatures? Obviously it would be better if this were upstream, but unless Linus changes his mind here (seems unlikely), MSFT starts signing X509 certificates (very unlikely), or some other centralized signing authority arises and gains enough market share to have their keys preinstalled (ha!), there doesn't seem to be a better solution.

On the other hand, maybe we should just go with (1) and let the vendors choose between pressuring MSFT to sign X509 certs or submitting their drivers to mainline.

Another thought

Date: 2013-02-28 12:03 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawlCU1zTyt93a3dVM62Sb4a2z7MnZfTnsoY
Somewhat tangential to this issue, but something that might help in discussions like these is hammering home the distinction between the shim/LF bootloader use case and the signed kernel use case. A lot of people seem to think that you're worried about shim's key being revoked, or that MSFT has already approved of shim so why does this matter, when this is really about a separate issue.

That being said, some of the people involved in the discussion (on both sides, but particularly notable was Greg KH insisting that signed modules don't matter) seem utterly disingenuous and that nothing will be done until a POC attack is demonstrated and MSFT starts the revocation process.


Date: 2013-02-28 05:35 pm (UTC)
From: (Anonymous)
One of the primary issues here is that regarding Microsoft as the sole signing authority in terms of booting computers is absurd. Rather than spending effort creating shims and bootloaders distributions should be getting together with the Linux foundation and installing a signing key in OEM hardware.

Can't be done? Dell/HP would be highly agreeable.

Key management is inconvenient for users? These are Linux users we're talking about. If they need to be protected from themselves, they shouldn't be exposed to it. If they're advanced users they can simply disable secure boot and carry on.


Date: 2013-02-28 06:45 pm (UTC)
From: (Anonymous)
Why do you think that Dell / HP would be agreeable? Some of us have actually talked to them, and perhaps they didn't agree to that type of thing at all.

Remember, HP and Dell are members of the Linux Foundation, so if they really wanted the Linux Foundation to do such a thing, the LF would.

greg k-h


Date: 2013-03-01 03:04 pm (UTC)
From: (Anonymous)
I doubt the conversation has been had more than once, and I imagine it was furtive. It would be a prudent move to have the conversation once again now that Windows 8 has demonstrably not done well.

Was Google / Canonical / Valve involved in cheerleading for the discussion? They should be. A second approach to the topic would be a good idea.


From: (Anonymous) - Date: 2013-03-03 04:44 am (UTC) - Expand
From: (Anonymous)
Matthew Garrett there is nothing to say in future all EFI machines will have the Microsoft key. You can fairly much bet a Chromebook if it ends up EFI will be missing it.

Here is a nice stupid question.
"The problem we have is that Microsoft won't sign X509 certificates, and there's no way to turn a PE/COFF signature into an X509 signature."
So you are not allowed to place a X509 certificate with X509 self signed signature and in a extra section in the PE/COFF that Microsoft is going to sign. Of course be creative that its the the extra X509 certificate and signature is to prevent MS tampering in the signing process. You can check against vendor if the certificate is correct.

That would provide a solution. To turn to Linux binary cut of MS signing. This also allows a key per vendor. Now If I have a Nvidia video card I don't need to load ATI drivers. Currently with the Microsoft signing solution its possible for me to load ATI drivers. Nice if ATI releases a buggy driver that gets past MS signing. Now the reverse could be true.

--if a bad person can get things signed by Microsoft, the bad person can already give you a package containing a backdoored bootloader.--

Matthew Garrett this is why the current mono culture of signing cannot remain. If I have taken the platform key and the KEK and removed the Microsoft keys. A Microsoft back doored bootloader is not going to work.

The reality here is you should be providing two bootloaders from redhat. One Signed by Microsoft. The Other signed by Redhat. Both binary identical other than the signing. Or you work out someway to get both signatures in 1 binary. Vendor signature and validators signature are required to prevent tampering.

Mattew Garrett how would we confirm that the Microsoft key is breached if you don't self sign something. Reason for doing this is then two keys would have to be breached not one.

Next for module loading should the Linux kernel trust the KEK most likely not. Multi OS install the keys in KEK are most likely too allowing.

Reality is most like the Linux kernel should for module signing only accept keys in the MOK that owns to the distribution. Like something signed by redhat for the redhat kernel really should not load in the Ubuntu kernel and vice verse. Normal API barriers currently prevent this but if you start making universal binary interfaces this is going to fail.

Next as you should remember Matthew Garrett from when Fedora changed the block size of memory. Distributions need to be able to blacklist modules Microsoft has approved. Reason Microsoft is only checking against will it work with Microsoft Windows not will not not do something stupid to a Linux install.

Re: What about the case I have taken the Platform key.

From: (Anonymous) - Date: 2013-03-01 01:51 pm (UTC) - Expand


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