[ 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. st...@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.
