Our Planned Approach to Secure Boot

In this follow-on blog to UEFI Secure Boot, I will describe our plans towards UEFI Secure Boot. Note that when we say “SUSE”, we really mean two very distinct distributions –  SUSE Linux Enterprise on one hand, and openSUSE on the other hand. The latter, being a  community project, is rather independent in their decisions on how to address the issue –  so the description below should be considered as the current Plan of Record for SUSE Linux Enterprise, but in the context of openSUSE, it can be a proposal for the community’s consideration only.

As explained in the previous installment of this series, UEFI Secure Boot is a useful technology, making it harder for attackers to hide a rootkit in the boot chain.

And at the same time, already the basics of its operation – establishing a single root of trust – conflict with the principles of Open Source development, which must be independent and distributed to work.

On top of that, there are a number of licensing and legal headaches waiting for anyone who wants to make use of Secure Boot in its default form. The GPL v3 anti-tivoization clause being one, another one being the wording of Microsoft’s SysDev contract that precludes the  signing of GPLv3 binaries with a Microsoft-provided certificate.

Currently, the first desktop systems are shipping with Secure Boot support, and we expect it to become pervasive in all newly sold PCs toward the end of this year. And of course we expect all of them to be shipped with Microsoft’s Key Exchange Key (KEK) installed by default.

Some of these new machines will probably have a way to disable secure boot easily; in others it may be possible but cumbersome; and in still others it may be impossible without loss of other functionality.

Supporting UEFI Secure Boot essentially boils down to having a boot loader with a digital signature that the firmware recognizes as a trusted key, and in order to be useful to Enterprise customers, that key should be trusted by the firmware a priori, without requiring any manual intervention.

There are two ways of getting there. One is to work with hardware vendors to have them endorse a SUSE key which we then sign the boot loader with. The other way is to go through Microsoft’s Windows Logo Certification program to have the boot loader certified and have Microsoft recognize our signing key (i.e. have it signed with their KEK). We are currently evaluating both approaches, and may eventually even pursue both in parallel.

At the implementation layer, we intend to use the shim loader originally developed by Fedora – it’s a smart solution which avoids several nasty legal issues, and simplifies the certification/signing step considerably. This shim loader’s job is to load grub2 and verify it; this version of grub2 in turn will load kernels signed by a SUSE key only. We are
currently considering to provide this functionality with SLE11 SP3 on fresh installations with UEFI Secure Boot present.

Now it is probably clear why this approach offers the level of security that UEFI Secure Boot promises – there is an unbroken chain of verification, making sure only trusted and signed code gets executed prior to handing control to the Operating System kernel.

What isn’t clear is how this allows Open Source developers to run their own kernels, or bootloaders for that matter or how this complies with the GPL v3 license. In the next part of this series of blogs, we will explain how we intend to provide this with our version of the shim.