[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: EFI in Debian



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

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: