Loading keys from Microsoft PE binaries

The work done at Red Hat, SUSE, the Linux Foundation, and elsewhere is sufficient to enable a distributor to ship a binary distribution that will boot on a secure-boot-enabled system. Such distributions are often built so that they will only load kernel modules that have been signed by a trusted key, normally the distributor's own key. That restriction naturally causes problems for companies that ship binary-only modules; such modules will not be loadable into a secure-boot system. Many developers in the kernel community are not overly concerned about this difficulty; many of them, being hostile to the idea of binary-only modules in the first place, think this situation is just fine. Distributors like Red Hat, though, are not so sanguine.

One solution, of course, would be for those distributors to just sign the relevant binary modules directly. As Matthew Garrett points out, though, there are a number of practical difficulties with this approach, including the surprisingly difficult task of verifying the identity and trustworthiness of the company shipping the module. There's also the little problem that signing binary-only modules might make Red Hat look bad in various parts of our community and give strength to those claiming that such modules have no GPL compliance problems. So Red Hat would like to find a way to enable proprietary modules to be loaded without touching them directly, allowing the company to pretend not to be involved in the whole thing.

Red Hat's solution is to convince the kernel to trust any signing key that has been signed by Microsoft. Binary module vendors could then go to Microsoft to get their own key signed and present it to the kernel as being trustworthy; the kernel would then agree to load modules signed with this key. This only works, of course, if the kernel already trusts Microsoft's key, but that will be the case for all of the secure boot solutions that exist thus far. There is one other little problem in that the only thing Microsoft will sign is a PE binary. So Red Hat's scheme requires that the vendor's key be packaged into a PE binary for Microsoft to sign. Then the kernel will read the binary file, verify Microsoft's signature, extract the new key, and add that key to the ring of keys it trusts. Once that is done, the kernel will happily load modules signed by the new key.

This solution seems almost certain not to find its way into the mainline kernel. In retrospect, it is unsurprising that a significant patch that is seen as simultaneously catering to the wishes of Microsoft and binary module vendors would run into a bit of resistance. That is even more true when there appear to be reasonable alternatives, such as either (1) having Red Hat sign the modules directly, or (2) having Red Hat sign the vendor keys with its own key. Such solutions are unpopular because, as mentioned above, they reduce Red Hat's plausible deniability; they also make revocation harder and almost certainly require vendors to get a separate signature for each distribution they wish to support.

Linus has made it clear that he is not worried about those problems, though. Security, he says, should be in the control of the users; it should not be a mechanism used to strengthen a big company's control. So, rather than wiring Microsoft's approval further into the kernel, he would rather that distributors encourage approaches that educate users, improve their control, and which, he says, would ultimately be more secure. Loading a module in this environment, he said, would be a matter of getting the user to verify that the module is wanted rather than verifying a signing key.

The other reason that this patch is running into resistance is that there is widespread skepticism of the claim that the loading of unsigned modules must be blocked in the first place. Proponents claim that module signing (along with a whole set of other restrictions) is needed to prevent Linux from being used as a way to circumvent the secure boot mechanism and run compromised versions of Windows. Microsoft, it is said, will happily blacklist the Linux bootloader if Linux systems are seen as being a threat to Windows systems. Rather than run that risk, Linux, while running under secure boot, must prevent the running of arbitrary kernel code in any way. That includes blocking the loading of unsigned kernel modules.

It seems that not all kernel developers are worried about this possibility. Greg Kroah-Hartman asserted that module signature verification is not mandated by UEFI. Ted Ts'o added that Microsoft would suffer public relations damage and find itself under antitrust scrutiny if it were to act to block Linux from booting. It also seems unlikely to some that an attacker could rig a system to boot Linux, load a corrupted module, then chain-boot into a corrupted Windows system without the user noticing. For all of these reasons, a number of developers seem to feel that this is a place where the kernel community should maybe push back rather than letting Microsoft dictate the terms under which a system can boot on UEFI hardware. But some of Red Hat's developers, in particular, seem to be genuinely afraid of the prospect of a key revocation by Microsoft; Dave Airlie put it this way:

Others counter that, if Microsoft can revoke keys for any reason, there is little to be done to protect the kernel in any case.

In the end, this does not appear to be an easy disagreement to resolve, though some parts are easy enough: Linus has refused to accept the key-loading patch, so it will not be merged. What may well happen is that the patch will drop out of sight, but that distributors like Red Hat will quietly include it in their kernels. That will keep this particular disagreement from returning to the kernel development list, but it does little to resolve the larger question of how much Linux developers should be driven by fear of Microsoft's power as they work to support the UEFI secure boot mechanism.