On 10 August 2012 11:40, Andreas Jaeger
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'll be brutally honest, and admit that I don't have a huge amount of knowledge with UEFI and Secure Boot. Saying that though, having read the excellent blog posts that explained things very clearly (great job!), I too would like to see the same approach taken for openSUSE as our enterprise cousin intends. There are a couple of reasons, 1. It makes supporting things much easier and it continues the close relationship between both distros/products. 2. The fact that Red Hat's engineer that created the shim agrees and actually commends SUSE's approach kind of says volumes about the thought and finesse that has gone into the proposal. I have spoken to colleagues that are actually working on UEFI and Secure Boot about the proposal, and as such they are far better placed to pass judgement. They too think that it is a sane approach and actually somewhat clever, whith almost no draw backs. So yes, please can we see the same approach adopted for openSUSE? A decision needs to be made sooner rather than later. Regards, Andy -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org