Mailinglist Archive: opensuse-project (271 mails)

< Previous Next >
Re: [opensuse-project] UEFI situation
2012/6/25 Andreas Jaeger <aj@xxxxxxxx>:
On Monday, June 25, 2012 14:43:41 Chris Jones wrote:
So what was the decision/end result with the UEFI situation? Where
does OpenSUSE stand with the situation?

Btw. it's openSUSE - always with a small "o".

There's no decision yet from openSUSE.

A couple of guys are looking into the whole situation - not only from an
openSUSE perspective but also looking what to do for SUSE Linux
Enterprise. They seem to like the Fedora approach but nothing is decided

As one of the guys AJ mentioned who is working on the issue, I could
tell that two basic principles for openSUSE

1. We will not enroll KEKs to firmware (for openSUSE)
The reason is that openSUSE is an open and free distribution and
hosted by community. It's not an commercial distribution that sell on
market on OEM products. Enrolling KEK really conflicts the nature of
openSUSE, which should encourage distribute of the distribution, not
restrict it or even lock down the to the systems with on SUSE keys
installed. Also enrolling the keys requires some degree of partnership
with OEM and working with IBV for the solution, which is not open and
not possible for communities to participate.

2. Be equal or friendly with other distribution
That means the solution has to align with what most other distribution
be able to choose and would allow co-operate with them. This implies
the windows signing service would be used as it's an fair offer for
all with a universal key installed. Until there's another signing
authority recommended by uefi forum, this is the only possible way to

I think the decision would be Fedroa's proposed solution, that is we
have a first stage bootloader signed by Microsoft signing service and
a second stage bootloader signed by us, thus we can avoid to integrate
Ms signing process to our infrastructure (OBS or whatever) as it's
painful (a *real living person* is involved to authenticate) and we
still have flexibilities for signing our bootlo.

About the kernel and kernel modules signing, it's still in discussing,
at least in the summit 2012. We have to watch it closely as it could
be a complementary technology to secure boot, However my **personal**
opinion is that the authentication happens after ExitBootService()
should be considered mandate and should be up to the OSV to decide (as
we already leave the pre-boot environment which UEFI secure boot tends
to protect) .

Beside, ** I ** am thinking to provide better flexibilities to
Redhat's solutions. We based on it and made some changes that
we|communities think we should add, by means of a layer (1.5 stage
bootloader) between 1st and 2nd stage. Not sure it's feasible or
doable so far.

bootloader 1 (signed by MS) -> bootloader 1.5 (developed and signed by
SUSE) -> bootloader 2 (allow signed by user, whatever any bootloader
is allowed)

2. distro default loader choice, grub2 or other bsd loaders which
would impose little license issue
3. more freedom to user, for example they could sign their own
bootloader (if their certificate could placed in ESP or in UEFI
variable to feed to 1.5 loader)
3. other *measure boot* technology like TPM be integrate to replace
the auth happens in 1.5.
4. multiboot with other distribution's efi, if they are signed and
certs are in place.

Above are stayed as a thoughts of myself and I'd like to know anyone's
thinking about it .. I will continue in investigating it and hope that
it makes sense to work on such direction.


 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

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

< Previous Next >