Summary of the Secure Boot BoF at DC19 [long, late]
[ Please note the cross-post and Reply-To ]
Hi folks,
As promised, here's a summary of what was discussed at the BoF session
at DebConf19 in Curitiba. Apologies for the huge delay in posting -
life... :-/
Thanks to the awesome efforts of our video team, video of the session
is online [1]. I've taken a copy of the Gobby notes too, alongside my
small set of slides for the session. [2]
=====================================================================
Secure Boot. In Debian. In Buster. Really.
Sunday, 2019-07-21, 13:30
What is Secure Boot?
====================
Simply, it is a way for computer firmware to validate that the
boot-time binaries it runs are the right ones - they have not been
tampered with, e.g. infested by malware. This works using a chain of
signatures, based on public key crypto.
It is typically *not* designed to totally lock down what software a
user can run on their system. It *is* designed to stop boot-time
malware - verifying the boot loader and kernel means that the
operating system, virus checkers, (etc.) can be started in a
known-clean state.
UEFI Secure Boot is included and enabled by default in just about
every modern x86 machine. It can be disabled if desired, but it's
genuinely useful technology and we should be part of it.
In the Linux world
==================
Most of the Linux distro community have decided to use shim as part of
their UEFI Secure Boot support. Shim is a tiny, really simple
first-stage boot loader started by Matthew Garrett. It is well
audited, well understood, etc. It has a simple job: it is a single
piece of signed software that verifies and runs the next stage
bootloader (Grub). It's a collaborative project, with contributions
from many people in lots of the distributions.
Microsoft act as the Certification Authority (CA) for UEFI SB here -
for obvious reasons their key is present on almost all x86 computers
as shipped. They *don't* want to sign Grub, as it's too large and
complex and (importantly) they don't like the GPLv3 licence
there. Instead, Microsoft will sign the simple, small, BSD-licenced
shim. A team of cross-distro people are responsible for reviewing the
shim patches and builds that are presented for signing. Microsoft
trust us to do that job - they don't pretend to be experts in how shim
works.
Each distro builds a version of shim with their own key(s) embedded,
and those key(s) are used for validating further things that are
loaded: Grub, Linux, firmware update programs, etc.
Users can also enrol their own Machine Owner Key(s) (MOK) on the
system, and shim will also use those key(s) for validation. This is an
important feature - end users have control over the keys that are used
here.
In Debian, we use our own key to sign some of the binaries generated
by a small number of source packages: Grub, shim (helper binaries),
Linux (and modules) and fwupd/fwupdate. We *can* sign other things if
we need to, but we want to keep the list of signed packages small and
controlled. Anything that is signed here must have a good security
story, for obvious reasons.
There are restrictions applied *by default* to systems booted with SB
enabled. Examples:
1. Grub will refuse to boot unsigned kernels.
[ Ubuntu's signed version of Grub initially would allow booting
with unsigned kernels, but this was widely agreed to be a
mistake and things have now been changed here. ]
2. No non-free/out-of-tree kernel modules will be loaded by Debian's
kernel, as they will not be signed. It is possible for users to
sign them (via MOK, for example); Ubuntu have methods to do module
signing in a more automated fashion, but we haven't yet set up
similar in Debian. More on this later.
3. Hibernation is disabled. All the state of the hibernated system is
put into the hibernation space (swap); it's very difficult to
secure and validate that data so that a cleanly-booted system can
know to trust it. This might be solved in the future, but not yet.
Is this supported in Debian?
============================
YES! Finally!
Everything is deployed (since earlier in 2019) so that everything
should work on three architectures: amd64, i386, arm64. Most users are
likely to be on amd64, but the others should work too.
On arm64, a minor issue is that there has not been a single CA for
arm64 machines to use until very recently, so a lot of current
machines will need configuration to be able to secure
things. Microsoft has recently agreed to act as a CA here also, but it
may take time for this setup to turn up on common shipping hardware.
Our signed packages are pulled in using Recommends, to still allow
people to *not* have them installed if that is preferred. This means
that standard installation methods will be secure by default, but be
careful during installation of packages when using apt
--no-install-recommends.
An important target here is that SB should Just Work for people,
invisibly. Any problems are bugs that should be reported. As of the
Buster release, all of our debian-installer and live media for our
supported arches should work with SB enabled, and the secure setup
will also be propagated through to systems installed using either.
Debian's cloud images are not quite all set up with SB yet, but this
should hopefully be done soon. Lots of the cloud providers are very
much interested in this - they want to see trusted verification of
software too!
Debian infrastructure
=====================
Working out the best way to build signed packages using Debian
infrastructure has been the most "fun" part of this whole process. We
had *many* proposals over the last few years for how to do stuff, each
of which was found to be problematic.
In the end, binary packages that are signed in Debian will have two
variants, one signed and one unsigned. In most cases, the *signed*
binary package will be called $something-signed; for the linux kernel
packages, they instead are called linux-image-* (signed) and
linux-image-*-unsigned (for the unsigned version).
Building the signed packages for the Debian archive is slightly
complex, but here's how it works:
1. Each source package that needs to build a signed binary package
($package-$arch-signed) now also generates pseudo-source template
packages called $package-$arch-signed-template. The template
package contains two things:
a. metadata to describe exactly what binaries should be signed,
and how;
b. a skeleton source package to describe how to build
$package-$arch-signed
2. There are now 2 buildd passes for source packages that are wanting
to build signed binary packages, and in the middle of that a new
service that we have called the "signing service".
a. [buildd pass 1]
The existing buildd pass to make binary packages, just as we
had previously.
b. [signing service]
*Iff* the source package builds -signed-template packages *and*
the package is on an allowed list (controlled by ftpmaster),
then those -signed-template packages will be queued up for the
signing service (SS for short here).
The SS is utterly locked down, by design. The signing keys are
all stored in an HSM for extra security. It also runs *no* code
or scripts from the -signed-template packages that it is
processing, to minimise any attack surface here.
The SS parses the configuration from the -signed-template and
generates appropriate detached signatures for the desired
binaries. (These binaries will come from the normal buildd
output.)
The detached signatures are then combined with the skeleton
source package to make another source package
($package-$arch-signed). This new source package is then
uploaded into the buildd queue again.
c. [buildd pass 2]
The buildds pick up on the new version of $package-$arch-signed
and build binary packages to match. This involves simply
grabbing binaries again and attaching the included signatures.
This second buildd pass allows us to have the separation of
code and data here - it's how we can generate signed binary
packages without having to run debian/rules (etc.) on the
signing service.
We want 100% reproducibility for everything that we sign, of
course. All of the code we have for the signing service (etc.) is of
course open and freely available. We want total transparency for what
we're doing here - that's how we can all trust it.
More details about the design of the signing service and our process
can be found online at https://wiki.debian.org/SecureBoot/Discussion
The awkward bits
================
Time
----
It's taken a *very* long time to get this into Debian. We've been
talking about this since ~2012, only in the archive in 2019. Why has
it taken seven years?
This is a very complex topic that required cross-team collaboration
from (at least!) 5 different teams in Debian: Kernel, EFI, FTP, DSA,
buildd.
Debian works really well when people can work independently - it's how
we have thousands of contributors working on tens of thousands of
different source packages without forever blocking each other.
But here we had busy people (and teams) waiting on each other,
multiple times. There there were several different proposals and we
needed many rounds of discussions before we eventually got to our
solution. Huge progress was finally made during a sprint in April 2018
in Germany when we had people from *all* the relevant teams together
in a room for the first time. It's amazing how much better things can
work when then feedback loop is measured in minutes rather than weeks!
Tooling
-------
Tooling is still not very friendly in the Secure Boot area. It's
security-related software, so it apparently has to be difficult to
use. Also, very few people use it and understand it well, so it's
still quite easy to find bugs and edge cases that others have not
yet. Docs are rare and out of date. This is not an attempt to be nasty
about the developers here - good software needs a certain number of
users to provide feedback and help find the bugs.
Bugs
----
Unfortunately, we will also now be using more firmware features so
we'll definitely discover more bugs, just as we found with switching
from BIOS boot to UEFI initially. Please report things as you find
them - that's always the best way to get them fixed.
Supporting non-free drivers
---------------------------
We still need to come up with a good solution to support SB users
needing non-free drivers (like the Nvidia binary graphics drivers). We
don't have anything really put together yet, but we can borrow
liberally from people like Ubuntu who have solutions for this.
The good bits
=============
Now, with UEFI Secure Boot, it's much easier (and safer) to install
Debian. We don't need to disable secure boot in the BIOS, or (worse!)
explain to other users how to do it on their systems.
We have *better* support for secured systems. We're still far from
supporting locking things down end-to-end here like some people
want/need, but it's progress.
User freedom really matters, of course. End users have the option to
disable all of the SB features if they desire, and that has been an
important consideration all along this process. Users also have the
ability to use their own keys alongside (or instead of) the default
keys on their system - full control of everything is possible here.
We have deliberately made all of our work here fully open so that
users can follow our process and even use our code to generate their
own signed packages if desired. This gives options for Free Software
end-to-end.
Thanks to everyone!
===================
I was doing the last pieces to tie all this together, but I was only
one of a number of people who spent effort to make SB a reality in
Debian. It was a lot of hard work for a number of people across
various teams in Debian! In the session, I particularly called out:
* Tollef Fog Heen
* Helen Koike
* Luke Faraone
* Ben Hutchings
* Joerg Jaspert
* Ansgar Burchardt
* Aurelien Jarno
* patient people in the release team :-)
for contributing to this effort. Hopefully this is a good feature that
people will appreciate!
Questions and discussion
=======================
Purism are using coreboot, not UEFI SB. Needs a different setup.
We've only done the common case here to start with (UEFI SB on
x86/arm64). Adding support for different secure methods is of course
possible! Patches are welcomed, especially for different
architectures. It's hard to test booting without access to
hardware. We designed our infrastructure to be flexible and
extensible. The current setup allows for more algorithms, signing
variants, etc. U-Boot with SB is happening - we'd like to support SB
on embedded devices too, not just servers and laptops.
We could also support other Roots of Trust if needed, not just the
Microsoft CA signature on our shim. There are potential worries about
compatibility and process delays if we tried to get multiple CA
signatures on a single shim binary. But we could easily have multiple
shim binaries, each signed by a different CA as the root for a SB
system.
Quite a few people are going to need support for non-free drivers for
their machines. Adding better support here is a big piece of work that
we should target. For now, such users will need to disable SB or work
out how to do it. Helping us work out the best process and documenting
it / automating it is a great way to get involved.
We had Some proposals from the audience about ways to do this
(e.g. integrating with DKMS). but we need to be careful about
risks. Needs more discussions, particularly on security trade-offs.
SB and lockdown will block people from doing some things, particularly
low-level debugging. By their very nature, security and low-level
access are basically incompatible! Lockdown design and patch work is
still ongoing in the kernel, so things here are fluid.
Secure boot and key setup will vary massively, depending on
platform. Small systems like Arm-based IoT things will most likely use
Arm Trusted Firmware (ATF) for a secure base and may have keys
embedded. Interfacing to those and giving a good SB story is still
work in progress.
Discussion on how to compile own kernel and use it with SB:
1. Build own kernel, add your own keys
2. Add your key to shim, or in the MOK database
3. Might require separate chain of keys
Debian has the signing service setup, which we needed to avoid the
requirement for manual signing (and giving access for to many people
for signing). When running on your own machine, manual signing might
be good enough. We don't know of anybody else trying to run a signing
service using our code, so expect to find rough edges for now!
Further questions and problems
==============================
Please talk to us by mail (debian-efi@lists.debian.org) or IRC
(#debian-efi), and definitely file bugs as you find them. We want to
make this work for people.
[1] https://meetings-archive.debian.net/pub/debian-meetings/2019/DebConf19/secure-boot-in-debian-in-buster-really.webm
[2] https://www.einval.com/~steve/talks/Debconf19-SecureBoot/
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters are forecast."
Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Reply to: