[ Please note the cross-post and Reply-To ]

Hi folks,

Here's a summary of what we discussed in the EFI BoF [1] last week
(9th July). Thanks to the awesome efforts of the DebConf video team,
the video of the session is already online [2] in case you missed
it. I've also attached the Gobby notes that were taken during the
session. Again, thanks to the people who took part - we had a useful
discussion.

UEFI - background
=================

Newer PCs are now coming with a BIOS replacement (UEFI). This provides
a very different set of firmware interfaces to the traditional BIOS
that will require different boot methods. For now, PC motherboards are
continuing to ship with legacy BIOS support but this won't last
forever. In Debian, we need to make sure we build in support for UEFI
in various places:

* debian-installer
* boot CDs (both installer and live)
* boot loader(s)

There is also a second part to this puzzle: Microsoft's Secure Boot
specification. System vendors wanting MS certification for their
hardware (i.e. just about all vendors) will be required to ship their
hardware with Secure Boot enabled by default, although they will also
be required (on x86 systems) to include a method for end users to
disable Secure Boot somehow. Buyers of Windows systems based on ARM
CPUs will *not* get the same freedom.

Supporting UEFI
===============

We already have some of the necessary components in Debian, but we
need to make sure that we support things all the way from initial
CD/USB/network boot through installation and partitioning to
installing an EFI-capable boot loader. People are planning on tackling
this, hopefully in time for the Wheeze release. This should not be
*too* difficult, we hope.

Most of the session was taken up by discussion of...

Secure Boot (or should that be "Restricted Boot"?)
==================================================

We're most likely too late to do much about this in Debian for
Wheezy. There's a lot of work that would be needed, and a lot of
decisions to be taken. I was hoping that this BoF might be the venue
for those decisions, but that was too optimistic about what might
happen in a 45-minute session.

What we should expect: if Debian does not implement SB, then users
wishing to install Debian on MS-certified hardware will have a much
more awkward experience than previously, needing to navigate through
the firmware setup interface on their machine to find the place to
disable SB before. Only then will they be able to boot install/live
media. It will be difficult for us to help much on this front.

What others have done/said about SB
===================================

* Fedora - RedHat
* Everything signed
* Full signing of the kernel stack. You even have to sign modules, so it
complicates stuff for things like DKMS.

* Ubuntu - Canonical
* not persuaded that it is safe to use GPLv3 bootloaders - differs from
FSF view of the issue under best current legal advice with respect to
their pre-installed requirements in-house.
* for now avoids going the path of fully signing the kernel stack
* for now: prevent the user to have anything to do with BIOS, SecureBoot
key handling, etc.

* FSF
* Tend to think that GPLv3 issues (such as risking the obligation to
release private key content) are either not an issue or that the license
can be changed to avoid them
<http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web>

Future UEFI SB changes
======================

Comes down to MS certification requirements as to what actually ships. Must be
possible to disable SecureBoot but will practically be done via access to the
firmware: usability obstacle. No clarity on how users can install their own
keys, down to particular vendor variability. Part of the spec but not
necessarily implemented by vendors - best effort only and might not work for
all.

Likelihood of changes in MS requirements via public pressure vs pressure on OEMs?
MS are not an implementor, certifier instead. Working with individual OEMs
won't provide 100% coverage. Some clarifications have been made as a result of
bad press from the initial announcements.

Note: MS trying to implement a different mechanism / monopoly play on ARM, including
no requirement for SecureBoot to be capable of being disabled on ARM. Increasing
deployment of ARM devices will become important. Makes Windows phones much less
appealing as hackable devices.

Larger customers may be able to stipulate particular configurations or OS-less
hardware but this isn't just a hobbyist problem.

Reasons behind the spec include virus protection which is being pushed by some
of the larger customers for the hardware. HP want users to run what they want
to run but also take into account requirements from the same customers about
protecting what does run.

Debian and SB?
==============

What are the limitations on extra keys? Is another key useful?
* could be unlikely to get a response
* actual space within the firmware is limited
Any one binary can only be signed by one key.

Could we get (somebody like) Linux Foundation to sign a generic
bootloader for the distros? Unlikely, plus concerns about it being
seen as an untrusted virus vector...

It is quite possible that one or more OEM's will simply not bother to implement
the option to disable SecureBoot or put it in but not adequately test it. Current
certification requires a switch to be available but no requirement for this to
be obvious. Turned off, the machine cannot or may not be able dual-boot Windows8
depending if turning it off means switching firmware to BIOS compatibility mode
or just not cheching the signature from EFI. Corporate customers
may also require that SecureBoot is not turned off.

Derivatives will expect to be able to use Debian as a base. We may be
able to treat a signed bootloader as non-free, but that makes things
very difficult for the derivatives...

Conclusions
===========

We will need much more discussion before we get anywhere useful wrt
SecureBoot. In the mean time, we're going to concentrate on UEFI boot
which will be needed anyway.

[1] http://penta.debconf.org/dc12_schedule/events/925.en.html
[2] http://meetings-archive.debian.net/pub/debian-meetings/2012/debconf12/high/925_EFI_in_Debian.ogv

--
Steve McIntyre, Cambridge, UK. steve@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
afraid I'll miss my stop" -- Vivek Dasmohapatra
== EFI in Debian ==

Please take notes here
What do we do?
Two parts to this:
EFI boot itself
* easy - not trivial, not implemented in installer/debian-cd yet.
* SMOP
Secure boot
* what's the least bad way?
Others:
* Fedora - RedHat
* Everything signed
* Full signing of the kernel stack. You even have to sign modules, so it
complicates stuff for things like DKMS.
*
* Ubuntu - Canonical
* not persuaded that it is safe to use GPLv3 bootloaders - differs from
FSF view of the issue under best current legal advice with respect to
their pre-installed requirements in-house.
* for now avoids going the path of fully signing the kernel stack
* for now: prevent the user to have anything to do with BIOS, SecureBoot
key handling, etc.
* FSF
* Tend to think that GPLv3 issues (such as risking the obligation to
release private key content) are either not an issue or that the license
can be changed to avoid them
<http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web>

New hardware for x86 shipping to run Windows8, enabling SecureBoot by default
for Windows certification. Ordinary users will need support to work through
access errors: it's not clear how to disable SecureBoot (it will be different
in different devices) and, even though it will be possible for users to
install their own keys it's unclear how to do so. The EFI spec seems to
require it, but it might not be a MUST nor very clear how it would (or not)
be possible to do it.

Changes within EFI in future
----------------------------

Comes down to MS certification requirements as to what actually ships. Must be
possible to disable SecureBoot but will practically be done via access to the
firmware: usability obstacle. No clarity on how users can install their own
keys, down to particular vendor variability. Part of the spec but not
necessarily implemented by vendors - best effort only and might not work for
all.


Likelihood of changes in MS requirements via public pressure vs pressure on OEMs?
MS are not an implementor, certifier instead. Working with individual OEMs
won't provide 100% coverage. Some clarifications have been made as a result of
bad press from the initial announcements.

Note: MS trying to implement a different mechanism / monopoly play on ARM, including
no requirement for SecureBoot to be capable of being disabled on ARM. Increasing
deployment of ARM devices will become important. Makes Windows phones much less
appealing as hackable devices.

Larger customers may be able to stipulate particular configurations or OS-less
hardware but this isn't just a hobbyist problem.

Reasons behind the spec include virus protection which is being pushed by some
of the larger customers for the hardware. HP want users to run what they want
to run but also take into account requirements from the same customers about
protecting what does run.

Debian
======

What are the limitations on extra keys? Is another key useful?
* could be unlikely to get a response
* actual space within the firmware is limited
Any one binary can only be signed by one key.

Linux Foundation to sign a generic bootloader?


It is quite possible that one or more OEM's will simply not bother to implement
the option to disable SecureBoot or put it in but not adequately test it. Current
certification requires a switch to be available but no requirement for this to
be obvious. Turned off, the machine cannot or may not be able dual-boot Windows8
depending if turning it off means switching firmware to BIOS compatibility mode
or just not cheching the signature from EFI. Corporate customers
may also require that SecureBoot is not turned off.

Derivatives will expect to be able to use Debian as a base. May be able to treat a
signed bootloader as non-free. Try to support both users and derivatives at
the same time but it disables our standard install media without SecureBoot
first being disabled.

EFI support is still required in Debian Installer - BIOS won't be available
in future machines.

Hi Steve,

Thanks for the summary of the EFI BoF. If you don't mind, I'm going to
piggy-back on this to provide a bit more info about Secure Boot. Some of
this is just expanding on your notes with clarifications; other bits are new
information I've gleaned while attending the UEFI Summer Summit this week.
But don't ask me to remember which parts are which, as it's all run a bit
together in my head.

With many of my comments, I may be giving the impression that I think things
aren't that bad and that everything will be ok with Secure Boot. I am in
fact very concerned about Secure Boot; we have some significant challenges
ahead for continued after-market compatibility with commodity machines as a
result of this change. But to meet those challenges, we need to be focused
on the issues that are actually going to cause a problem. For instance, I
*don't* think we should be worried that machines will go out the door with
the Windows 8 logo on them while failing to correctly implement SB
(including the disable and customization capabilities). The Microsoft team
working on this are quite serious about getting it right, and they do have
a compliance testing process that exercises the SB aspect of the
requirements. So while there may be a machine or two slipping through to
market that don't support SB in the required manner, these would be bugs -
and I have every reason to believe Microsoft will be open to bug reports
about them.

The things that are worrying me, and that I therefore think we need to focus
on, are the areas where the Win8 requirements *don't* cover us.

On Fri, Jul 20, 2012 at 11:34:13PM +0100, Steve McIntyre wrote:
> There is also a second part to this puzzle: Microsoft's Secure Boot
> specification.

Nitpick: Secure Boot is part of the UEFI specification; the part here that's
Microsoft's is the policy around how SB is to be used.

> System vendors wanting MS certification for their hardware (i.e. just
> about all vendors) will be required to ship their hardware with Secure
> Boot enabled by default

Bearing in mind that they're only required to do this for Windows 8
certification. Some machines may ship with Windows 8 preinstalled, but not
have SB enabled and thus not be certified; some may continue to ship with
Windows 7; some server machines may (at least in the short term) come with
firmware that doesn't implement Secure Boot.

And some vendors may ship with Windows 8 preinstalled but fail the Win8
certification requirements because they've managed to not actually support
disabling SB and/or updating keys. Small comfort that this will result in
them not being able to use the Windows 8 logo if it means we won't be able
to use the machines at all.

Ironically this last bit means that the Windows 8 logo may wind up being the
*best* indicator of Linux compatibility for UEFI hardware. Only time will
tell what we see in the market.

> Future UEFI SB changes
> ======================

> Comes down to MS certification requirements as to what actually ships.
> Must be possible to disable SecureBoot but will practically be done via
> access to the firmware: usability obstacle.

More than just a practical implementation detail, it's by design that you
will only be able to disable SecureBoot via the firmware. To allow a UEFI
application to disable SecureBoot for you noninteractively would almost
completely undermine the security model. Now, I can't actually think of a
way that a UEFI application that *only* disabled SB could be used to
compromise a machine remotely; but it's in the Windows 8 reqs that the
firmware must not allow SB to be disabled programmatically.
(System.Fundamentals.Firmware.UEFISecureBoot 18)

> No clarity on how users can install their own keys, down to particular
> vendor variability.

James Bottomley appears to be addressing this:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git

Provided you can get the machine into setup mode or custom mode in the first
place (which is supposed to be guaranteed by the Win8 reqs), the tools here
should allow you to non-interactively install your own keys without
resorting to the vendor's firmware UI.

> Part of the spec but not necessarily implemented by vendors - best effort
> only and might not work for all.

FWIW, my understanding is that MS's logo compliance testing is expected to
catch this case.

> It is quite possible that one or more OEM's will simply not bother to
> implement the option to disable SecureBoot or put it in but not adequately
> test it. Current certification requires a switch to be available but no
> requirement for this to be obvious. Turned off, the machine cannot or may
> not be able dual-boot Windows8 depending if turning it off means switching
> firmware to BIOS compatibility mode or just not cheching the signature
> from EFI.

Hmm, I don't remember this being discussed during the BoF. I think it's
clear from context that when the Win8 requirements speak of disabling Secure
Boot, they mean not enforcing Secure Boot /while still providing an EFI
environment/.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120721023249.GA2499@virgil.dodds.net">http://lists.debian.org/20120721023249.GA2499@virgil.dodds.net

On Fri, Jul 20, 2012 at 4:34 PM, Steve McIntyre wrote:

> Here's a summary of what we discussed in the EFI BoF [1] last week
> (9th July). Thanks to the awesome efforts of the DebConf video team,
> the video of the session is already online [2] in case you missed
> it. I've also attached the Gobby notes that were taken during the
> session. Again, thanks to the people who took part - we had a useful
> discussion.

One thing I don't think anyone has discussed yet is how key
transitions will work, if a distro-specific key is compromised, is the
OS able to update the SB keys?

> Any one binary can only be signed by one key.

Would it be possible/useful to circumvent this limitation by making
copies of the binary and then signing them?

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAKTje6EGV4vOSw2KeQgJVQqrZsf=R6WY0GZSwUOdQjqewshGm Q@mail.gmail.com


Tue Jul 31 23:30:01 2012
Return-Path: <devel-bounces@lists.fedoraproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
eagle542.startdedicated.com
X-Spam-Level:
X-Spam-Status: No, score=-2.2 required=5.0 tests=DKIM_ADSP_CUSTOM_MED,
DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,SPF_PA SS,T_DKIM_INVALID,
T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-Original-To: tom@linux-archive.org
Delivered-To: tom-linux-archive.org@eagle542.startdedicated.com
Received: from bastion.fedoraproject.org (bastion01.fedoraproject.org [209.132.181.2])
by eagle542.startdedicated.com (Postfix) with ESMTP id 9AB9F20E008F
for <tom@linux-archive.org>; Tue, 31 Jul 2012 22:42:51 +0200 (CEST)
Received: from lists.fedoraproject.org (collab03.vpn.fedoraproject.org [192.168.1.70])
by bastion01.phx2.fedoraproject.org (Postfix) with ESMTP id E877420EB5;
Tue, 31 Jul 2012 20:42:48 +0000 (UTC)
Received: from collab03.fedoraproject.org (localhost [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id 4A472420B1;
Tue, 31 Jul 2012 20:42:48 +0000 (UTC)
X-Original-To: devel@lists.fedoraproject.org
Delivered-To: devel@lists.fedoraproject.org
Received: from smtp-mm01.fedoraproject.org (smtp-mm01.fedoraproject.org
[80.239.156.217])
by lists.fedoraproject.org (Postfix) with ESMTP id 377D940829
for <devel@lists.fedoraproject.org>;
Tue, 31 Jul 2012 20:42:46 +0000 (UTC)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com
[209.85.212.169])
by smtp-mm01.fedoraproject.org (Postfix) with ESMTP id 7C7DBC0079
for <devel@lists.fedoraproject.org>;
Tue, 31 Jul 2012 20:42:45 +0000 (UTC)
Received: by wibhm2 with SMTP id hm2so3901299wib.2
for <devel@lists.fedoraproject.org>;
Tue, 31 Jul 2012 13:42:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding;
bh=Cv5gAUgVyw8n0mZHu+IuOAVCBCOm6zN07eEMENbuwmk=;
b=miMlDLq4ohmHkPSPQpZe/eiHZMsxUn3j20oMNgjZ9UODFF45qONibB180csCMRCalB
oxxUzNKPsuCVfYDPwrDSs59h4HGPVqVXjtNvDWJlZs8gTSddu6 viiE89sKFzWLf3b/fm
TFER7SiSVzitoMk+QKT4Uk2ILYeEjgYAYHlgKTG8SxkJLKs8ID enUSPPuQKumQwvu/91
Zch2SlmiqxRz6qI/s2UYN3fLfLPsXyrDP6WTDKbnGa7TqKdjiJZ8xJxTXC6+WCPGQa 91
vT2aHLfCfk/waJu+IwrxvmKbhd2jRATnig56ExrAXjBuLOfUGNNtpnLtkgIyy TvdKZSE
eojg==
Received: by 10.180.78.37 with SMTP id y5mr5773983wiw.16.1343767365922;
Tue, 31 Jul 2012 13:42:45 -0700 (PDT)
Received: from localhost.localdomain (85-220-55-128.dsl.dynamic.simnet.is.
[85.220.55.128])
by mx.google.com with ESMTPS id ef5sm2869743wib.3.2012.07.31.13.42.39
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 31 Jul 2012 13:42:45 -0700 (PDT)
Message-ID: <5018430F.8050202@gmail.com>
Date: Tue, 31 Jul 2012 20:41:51 +0000
From: =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
<johannbg@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: devel@lists.fedoraproject.org
Subject: Re: F17 PM Test day late recap
References: <1075597839.2623675.1343741459608.JavaMail.root@re dhat.com>
In-Reply-To: <1075597839.2623675.1343741459608.JavaMail.root@re dhat.com>
X-BeenThere: devel@lists.fedoraproject.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Development discussions related to Fedora
<devel@lists.fedoraproject.org>
List-Id: Development discussions related to Fedora
<devel.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/options/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/devel/>
List-Post: <mailto:devel@lists.fedoraproject.org>
List-Help: <mailto:devel-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: devel-bounces@lists.fedoraproject.org
Errors-To: devel-bounces@lists.fedoraproject.org

T24gMDcvMzEvMjAxMiAwMTozMCBQTSwgSmFyb3NsYXYgU2thcn ZhZGEgd3JvdGU6Cj4gRHVyaW5n
IHRoZSBldmVudCBpdCBwcm92ZWQgdGhhdCBtYW5hZ2luZyBkb3 plbnMgb2YgYXR0ZW5kYW50cyBi
ZWNvbWUKPiBwYWluIHdpdGggdGhlIGN1cnJlbnQgdGVzdCBkYX kgaW5mcmFzdHJ1Y3R1cmUuIEZv
ciBuZXdjb21lcnMgaXQgd2FzCj4gaGFyZCB0byB1bmRlcnN0YW 5kIGhvdyB0byBmaWxsIHJlc3Vs
dHMgaW50byB3aWtpIChvciB0aGUgY29uY2VwdCBvZgo+IHRoZS B3aWtpIGl0c2VsZikuIEl0IHdh
cyBldmVuIGhhcmRlciBmb3IgcmVtb3RlZXMuIFNldmVyYWwgdG ltZXMgd2UKPiByZWNlaXZlZCBw
bGFpbiB0ZXh0IHJlcG9ydHMgYW5kIHdlIGhhZCB0byB0cmFuc2 ZlciB0aGVtIGludG8gd2lraQo+
IG91cnNlbGYuIEluIHJ1c2ggaG91cnMgdGhlcmUgd2VyZSBzby BtYW55IGNvbmZsaWN0aW5nIGVk
aXRzIGluIHRoZQo+IHdpa2kgdGhhdCB3ZSBoYWQgdG8gdXRpbG l6ZSBvbmUgcGVvcGxlIHdobyB3
b3JrZWQgb25seSBhcyBhIHdpa2kKPiBjb3JyZWN0b3IuIEkgY2 Fubm90IGltYWdpbmUgaG93IHRv
IGhhbmRsZSBlLmcuIGRvdWJsZSBudW1iZXIgb2YKPiBwYXJ0aW NpcGFudHMgd2l0aCB0aGUgY3Vy
cmVudCBzeXN0ZW0uIEkgdGhpbmsgdGhhdCBzb21lIG1vcmUgcm 9idXN0Cj4gYW5kIGludHVpdGl2
ZSBzeXN0ZW0gaXMgbmVlZGVkIHRvIGF0dHJhY3QvaGFuZGxlIG 1vcmUgcGFydGljaXBhbnRzLgo+
IElmIGRlc2lnbmVkIHRoZSByaWdodCB3YXkgaXQgY291bGQgYW xzbyBzaW1wbGlmeSBldmFsdWF0
aW9uIG9mIHJlc3VsdHMKPiBhbmQgY291bGQgZ2l2ZSBhbnN3ZX JzIHRvIHZhcmlvdXMgcXVlcmll
cyBsaWtlICJ3aGF0IEhXIHdvcmtlZCBvbgo+IHdoaWNoIHZlcn Npb24gb2YgRmVkb3JhIi4KCkF0
IHRoZSB0aW1lIHdlIGxvb2tlZCBhdCB2YXJpb3VzIHRlc3Rpbm cgc3lzdGVtIGJ1dCBhbGwgb2Yg
dGhlbSBmZWxsIApzaG9ydCBvbmUgd2F5IG9yIGFub3RoZXIgdG h1cyB3ZSBkZWNpZGUgdG8gc2V0
dGxlIG9uIHNvbWV0aGluZyByZXBvcnRlcnMgCndoZXJlIGZhbW lsaWFyIHdpdGggYXMgYW4gc2hv
cnQgc3RvcCB1bnRpbCB3ZSBmb3VuZCBvciBjYW1lIHVwIHdpdG ggCnNvbWV0aGluZyBiZXR0ZXIg
YW5kIHdlIGhhZCBjb3VwbGUgb2YgaWRlYXMgaG93IHRoYXQgc2 hvdWxkIGxvb2sgbGlrZSAKd2hp
Y2ggd2VsbCBsZXQncyBzYXkgd2FzIHF1aXRlIGRpZmZlcmVudC Bmcm9tIHRoZSB0cmFkaXRpb25h
bCB0Y21zLgoKSW4gYW55IGNhc2UgdGhpcyBkaXNjdXNzaW9uIG FuZCBob3cgaXQgY2FuIGJlIGlt
cHJvdmVkIGJlbG9uZ3Mgb24gdGhlIAotdGVzdCBsaXN0IHdoZX JlIHRoZSBRQSBjb21tdW5pdHkg
cmVzaWRlcy4uLgoKSkJHCgoKLS0gCmRldmVsIG1haWxpbmcgbG lzdApkZXZlbEBsaXN0cy5mZWRv
cmFwcm9qZWN0Lm9yZwpodHRwczovL2FkbWluLmZlZG9yYXByb2 plY3Qub3JnL21haWxtYW4vbGlz
dGluZm8vZGV2ZWw=

On Tue, Jul 31, 2012 at 02:40:25PM -0600, Paul Wise wrote:

> > Here's a summary of what we discussed in the EFI BoF [1] last week
> > (9th July). Thanks to the awesome efforts of the DebConf video team,
> > the video of the session is already online [2] in case you missed
> > it. I've also attached the Gobby notes that were taken during the
> > session. Again, thanks to the people who took part - we had a useful
> > discussion.

> One thing I don't think anyone has discussed yet is how key
> transitions will work, if a distro-specific key is compromised, is the
> OS able to update the SB keys?

Any OS will be able to push signed updates to the DB and DBX variables,
adding new trusted keys or revoking keys / individual binaries. However,
the only signed updates that will be accepted by the firmware are those
signed by keys already trusted /by the firmware/ (i.e., those present in the
kEK). This means that in general, if you have a compromised key or
compromised binary, you need to go back to the CA (i.e., whoever is
providing a trust path back to KEK for you) and ask them to issue a
revocation.

> > Any one binary can only be signed by one key.

> Would it be possible/useful to circumvent this limitation by making
> copies of the binary and then signing them?

It's certainly straightforward to take copies of a single binary and have it
signed by multiple keys. It's even straightforward to remove one signature
from a binary and replace it with another. What's not straightforward is to
provide a single boot image that can reasonably make use of such things,
since UEFI boots by looking for a single well-known path to boot from.

FWIW the UEFI working group seems to consider it an oversight that only one
signature is allowed per binary, and work is afoot to correct this. But as
with other issues, it's probably too late to make a difference for the first
iteration of hardware.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

On Tue, Jul 31, 2012 at 02:28:28PM -0700, Steve Langasek wrote:
>On Tue, Jul 31, 2012 at 02:40:25PM -0600, Paul Wise wrote:
>
>> One thing I don't think anyone has discussed yet is how key
>> transitions will work, if a distro-specific key is compromised, is the
>> OS able to update the SB keys?
>
>Any OS will be able to push signed updates to the DB and DBX variables,
>adding new trusted keys or revoking keys / individual binaries. However,
>the only signed updates that will be accepted by the firmware are those
>signed by keys already trusted /by the firmware/ (i.e., those present in the
>kEK). This means that in general, if you have a compromised key or
>compromised binary, you need to go back to the CA (i.e., whoever is
>providing a trust path back to KEK for you) and ask them to issue a
>revocation.

Ah, right. I'd missed that part of the spec and I wasn't clear how
revocation is meant to work.

...

>FWIW the UEFI working group seems to consider it an oversight that only one
>signature is allowed per binary, and work is afoot to correct this. But as
>with other issues, it's probably too late to make a difference for the first
>iteration of hardware.

ACK. :-(

--
Steve McIntyre, Cambridge, UK. steve@einval.com
"C++ ate my sanity" -- Jon Rabone


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120804153338.GK32345@einval.com">http://lists.debian.org/20120804153338.GK32345@einval.com