Mailinglist Archive: opensuse-project (240 mails)

< Previous Next >
Re: [opensuse-project] UEFI Secure Boot
  • From: Andreas Jaeger <aj@xxxxxxxx>
  • Date: Wed, 08 Aug 2012 12:38:10 +0200
  • Message-id: <2409438.6kKrf6PRRD@byrd>
Part 2 is out at,


Text copied:
"Our Planned Approach to Secure Boot

August 8, 2012 10:13 am

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

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."

Andreas Jaeger aj@{,} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
To contact the owner, email: opensuse-project+owner@xxxxxxxxxxxx

< Previous Next >