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

Plan of action for Secure Boot support

Colin Watson and Stefano Rivera talked about how Ubuntu had implemented
Secure Boot and what they believed were the requirements.

Apparently, the Secure Boot spec requires each stage of the boot code to
validate signatures only until ExitBootServices() is called.  (At this
point the firmware makes some parts of its non-volatile configuration

While some users would probably like to be able to 'lock down' the
kernel, requiring signed modules and disabling other kernel features
that allow code injection, this does not seem to be a requirement for
booting on systems that implement Windows 8 logo requirements in the
usual way, i.e. that require a Microsoft-signed first stage boot loader.

There seemed to be a consensus that we could use an implementation quite
similar to Ubuntu's.  Some may be concerned that use of a Microsoft
signing key results in a non-free binary, but so long as the target
machines (amd64 architecture) generally allow installation of alternate
public keys this is not so different from the way that APT on a Debian
system requires Debian-signed Release files by default.

So the plan seems to be:

1. Colin Watson will prepare dak changes to support upload and subsequent
signing of EFI executables.  (This is an embedded, not detached, signature.)

2. Steve Langasek will prepare and upload a package of the 'shim' EFI
boot loader.  This will embed our own set of public keys (corresponding
to those used by dak) and can load any other EFI executable signed by
one of them.  Later, there will be a shim-signed package containing the
same executable with a Microsoft signature.  (This costs money and takes
several days, but shim should require only very infrequent changes.)

3. Colin Watson will update the GRUB package to build a to-be-signed
monolithic EFI executable separate from the package.  Then he will add a
grub-signed package that includes the Debian-signed executable from the
archive.  This executable would be suitable for use on both removable
media and the installed system.

4. The kernel team may also need to upload kernel images for signing and
add linux-image-signed packages with the Debian-signed kernel images.
This is because some quirks in the kernel should be run before calling


Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.

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

Reply to: