On Thu, 2012-07-05 at 22:27 -0400, Theodore Ts'o wrote: > On Wed, Jul 04, 2012 at 12:51:01PM +0000, Tanguy Ortolo wrote: > > Tanguy Ortolo, 2012-07-04 14:13+0200: > > > A blog post explaining how to set up Debian to boot via UEFI: > > > http://tanguy.ortolo.eu/blog/article51/debian-efi > > > A message to this list detailing the UEFI boot procedure and what is > > > required to support it: > > > <je7174$b6p$1...@dough.gmane.org> > > > http://lists.debian.org/debian-devel/2012/01/msg00168.html > > > > (basically, we already have everything needed to boot via UEFI (not with > > SecureBoot of course, though), only the Debian installer does not > > support it) > > James Bottomly has been doing some work to support Secure Boot. See: > > http://lwn.net/Articles/503820/ > > His work was done specifically to help other community distributions > beyond Ubuntu and Fedora. We (the LF Technical Advisory Board) are > currently investigating if there is more the LF can do to support > distributions. We're not in the position to promise anything just > yet, but if Debian has any suggestions of things that you might like, > do please let me know.
UEFI running in qemu is likely to be very useful for development of UEFI support by the Debian installer and Debian CD teams. Secure Boot is another matter, which I was planning to raise *after* the release as it's controversial and I don't think we have time to do anything about it for wheezy. But here's what I think we would need: 1. General consensus in the project that supporting the option of Secure Boot, including purchase of a Microsoft-signed certificate, is worthwhile and not entirely objectionable. (I am assuming that it would be a waste of time to use our own platform key, as anyone who can work out how to install that can also disable Secure Boot.) 2. Upstream kernel support: when booted in Secure Boot mode, Linux would only load signed kernel modules and disable the various debug interfaces that allow code injection. I'm aware that David Howells, Matthew Garrett and others are working on this. 3. A suitable free boot loader: when booted in Secure Boot mode it would only load signed EFI executables. There seem to be several projects under way to do this. 4. EFI code signing tool. Matthew Garrett seems to have that in hand. 5. Key management policy. Similar issues to archive signing keys, but these keys also need to be available at build time. (a) Should they be held by package maintainers and/or the auto-builders for the relevant architectures? (b) sbuild and/or pbuilder will need to know how to inject them into the build environment for the relevant packages. (c) How do we handle key replacement when exploitable code needs to be blacklisted? 6. User documentation: users need to be informed that when running Linux under Secure Boot some major features are disabled, and that they have the option to turn it off. (Or install their own platform key.) So, returning to your question: I think that LF may be able to help with 5(c), 6, and perhaps 3 (encouraging more coordinated development). Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson
signature.asc
Description: This is a digitally signed message part
