2012/6/25 Andreas Jaeger
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 yet,
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 go. 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. Thanks, Michael
Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} 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@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org