plain text this time On Fri, Aug 10, 2012 at 9:08 AM, Greg Freemyer <greg.freemyer@gmail.com> wrote:

On Fri, Aug 10, 2012 at 6:40 AM, Andreas Jaeger <aj@suse.com> wrote:

...

As a followup to discussions on opensuse-project and here on opensuse-factory about secure boot, here's a proposal:

Vojtech Pavlik and Olaf Kirch have written three blog posts explaing SUSE's approach to secure boot:

http://www.suse.com/blogs/uefi-secure-boot-overview/ http://www.suse.com/blogs/uefi-secure-boot-plan/ http://www.suse.com/blogs/uefi-secure-boot-details/

They basically propose to enhance Fedora's solution with a way that Matthew Garrett - the Red Hat developer working on this - summarized at http://mjg59.dreamwidth.org/15818.html with

"There's a post here describing SUSE's approach to implementing Secure Boot support. In summary, it's pretty similar to the approach we're taking in Fedora - a first stage shim loader is signed with a key in db, it loads a second stage bootloader (grub 2) that's signed with a key that's in shim, the second stage bootloader loads a signed kernel. The main difference between the approaches is the use of a separate key database in shim, whereas we are currently planning on using a built-in key and the contents of the firmware key database. ... "It's a wonderfully elegant solution. We've been planning on supporting user keys by trusting the contents of db, and the Windows 8 requirements specify that it must be possible for a physically present user to add keys to it. The problem there has been that different vendors offer different UI for this, in some cases even requiring that the keys be in different formats. Using an entirely separate database and offering support for enrolment in the early boot phase means that the UI and formats can be kept consistent, which makes it much easier for users to manage their own keys.

I suspect that we'll adopt this approach in Fedora as well - it doesn't allow anything that our solution wouldn't have, but it does make some of them easier. Full marks to SUSE on this."

What shall we do for openSUSE? Vojtech and Olaf make the proposal to use the proposed SUSE solution for openSUSE as well.

Do you see any problems or enhancements for the proposal?

I would love to tell them the openSUSE community looks forward to the SUSE implementation for the next release (12.3). May I?

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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I think there are 2 questions. 1) Is the SUSE approach with a standalone database of MOKs necessary for openSUSE. I argue it is. 2) Is the functionality defined for using that database of MOKs sufficient for openSUSE needs. I argue it is not. The prime examples relate to OBS and SuseStudio. If each of those is provisioned with a unique MOK key and the validation key is made well known, then the SUSE approach will I'm sure include a relatively simple way for a user to install the validation key into the MOK database. But what if OBS and/or SuseStudio is used to create a kernel that gets designated as malware. I would like to see the openSUSE solution provide a way to black ball that kernel. === Thus I think openSUSE should use the SUSE UEFI approach as a foundation, but should add a black ball mechanism to it somehow. I admit that I don't have a methodology in mind to accomplish that. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org