Plan of action for Secure Boot support

[Cyril Brulebois]

Hi,

many thanks for the summary.

Ben Hutchings <ben at decadent.org.uk> (2013-08-13):
> 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
> inaccessible.)
> 
> 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
> ExitBootServices().

(Sorry, I'm new to all this) do you mean (1) the regular linux image
packages are getting a signature added, and we're using those like we do
today, or (2) that we'll have additional linux image packages with the
signatures to be used instead of the usual linux image packages when a
Secure Boot environment is detected? (or (3) something else…)

[As a side yet relevant note: I think there's a general agreement that
we aren't going to target putting as many things as possible on a
regular CD like we used to do, so a few grub/bootloader things are
probably OK; having duplicate linux image packages wouldn't look too
nice though.]

Mraw,
KiBi.