No Microsoft certificate support in Linux kernel says Torvalds

Red Hat's Secure Boot support is a case of the company wanting to "deep-throat Microsoft", according to a forthright posting from Linus Torvalds on the Linux kernel developer mailing list. Torvald's comments were made in response to plans by a Red Hat developer to extend Linux support for Secure Boot. The comments have given rise to an ongoing discussion, during which several prominent kernel developers have shared their thoughts on Secure Boot support in Linux.

In submitting a collection of changes for merging into Linux 3.9, Red Hat developer David Howells has triggered a wide-ranging debate on the Linux Kernel Mailing List (LKML). The patches would have enabled the Linux kernel to verify binaries signed by Microsoft. For example, this would enable the Fedora 18 kernel, which, if Secure Boot is activated, only loads kernel modules signed by the Fedora project, to also load Microsoft-signed modules. The Linux kernel currently supports certificates meeting the X.509 standard. Microsoft, by contrast, has developed its own code-signing system in the form of Authenticode.

The Red Hat patches would enable companies such as AMD and NVIDIA to have the kernel modules for its graphics drivers signed by Microsoft, enabling distributions such as Fedora to load them even when Secure Boot is activated. Such a capability could also be of interest to systemtap modules. Red Hat does not itself offer a signature service and a Red Hat developer has stated unequivocally that the company will not be signing external modules. In the course of the debate on Howells' patches, Torvalds pointed out that the kernel already supports a system for verifying signatures – X.509 – but not the system used by Microsoft.

The debate has now morphed into a more general discussion of the implications of Secure Boot and Secure Boot support in the Linux kernel and Linux distributions. One of the more hotly debated issues is whether, in order to support Secure Boot, the Linux kernel itself needs to be signed and should only load signed modules, as is the case in Fedora 18. Such a procedure is not prescribed in the Secure Boot specification.

According to kernel developer Matthew Garrett, who coded secure bootloader shim (which is signed by Microsoft), it is, however, a contractual requirement for obtaining a Secure Boot signature from Microsoft. Microsoft also reserves the right to revoke a certificate if code signed with it compromises the security of UEFI. An unsigned kernel module would theoretically meet this criterion.

Whether Microsoft-compatible Secure Boot support requires the kind of restrictions introduced in Fedora 18 has long been disputed. The version of the bootloader shim used in Ubuntu 12.04.2 and 12.10 only checks the signature of GRUB 2. GRUB 2 will, however, happily boot unsigned kernels which will in turn load unsigned kernel modules. Secure Boot support in Ubuntu thus does not restrict users from, for example, using proprietary drivers from AMD and NVIDIA. In order to maintain the chain of trust, Fedora does impose such restrictions. For Ubuntu, therefore, the changes proposed by Howells are superfluous.

This issue is just one factor in a wide-ranging ongoing debate. The issue of why the Linux ecosystem does not set up its own infrastructure for signing (Linux) operating systems has also once again been raised. This particular issue comes down to cost – according to Greg Kroah-Hartman, setting up and running such an infrastructure would almost certainly cost more than the Linux Foundation's entire annual budget.

(fab)