# Current status
================

What are the requirements for secure boot for UEFI forum and Microsoft signature?

SHIM
====

shim does not need additional work, vorlon willing to complete it.
Needs to be uploaded sooner rather than later to allow time for MS to deal with it and sign for us.
Must generate the trusted key(s) first.

EFI variable to determine if secure boot is disabled?

DAK
===

signing infrastructure in dak pending - Ben has sent patches; they work for him in a local dak installation
jcristau volunteers to review
would be nice to get Debian and Ubuntu infrastructure compatible here, no reason
to be different. infinity and ben to co-ordinate

Debian bug with patches: https://bugs.debian.org/821051
Ubuntu implementation: https://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/archivepublisher/customupload.py
                       https://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/archivepublisher/signing.py
Ubuntu archive example: http://archive.ubuntu.com/ubuntu/dists/xenial-proposed/main/uefi/linux-amd64/4.4.0-30.49/

linux signed images are in unstable, default linux-image packages will be signed starting with 4.7

DKMS
====

Will a kernel load DKMS-built modules when SB enabled? Not by default.
Options in Ubuntu to allow loading of unsigned modules, or (coming) to add DKMS local signing.
Debian kernel doesn't yet load extra trusted signing keys but there is a protocol for shim to pass them to grub/kernel.
Using a local signing key has major security issues!

Signing of firmware images (/lib/firmware/*) is not yet enforced - discussing upstream.
  architecture discussions, code patches not seen at this stage.
Ben co-maintains the linux-firmware repo, but hasn't seen any efforts to add sigs yet

Key management
==============

need to work out HSMs - Tollef says keys trusted by shim are supposed to be in an HSM. But possibly only the key used to sign the shim upload to MS needs to be in an HSM.
need to work out multiple keys etc.
we have yubikeys, but nothing is in place yet to use them
Ubuntu keys are not in HSM at this stage.

Need to look at the security of the box holding the keys, e.g. ftp-master.
Methods will be reviewed by Microsoft. Submit the shim to be signed and
wait for questions.

Tollef will do the key and share it with a number of people, and get the
public part to vorlon for inclusion in shim.
Tollef will also get the EV code-signing cert organised. Vorlon might be able to help with advice

Grub
====

Code to not load unsigned things in secure mode is not in an upstream grub
release. Not clear whether it has been committed.
Grub is lagging without an actual release.

Live
====

EFI patches never went into live-build.
live-wrapper already does EFI and Secure will follow.
 use ovmf config to test secure boot once shim is the boot target
 instead of grub-efi when testing with QEMU.
 Neil to continue fixes on live-wrapper branch for bootable images,
 including adding support to install shim.
   - notify and work with Adam once branch is merged.
 Sledge to close the debian-live bug as un-needed
 minor changes still to come elsewhere
 
ARM64
=====

Install grub-signed - user / installer can take it out of setup mode
after installing keys. Potentially hostile to other vendors.
Problems with section alignment on arm64 too so far

Can include shim in the boot process as a pass-through and for uniformity but
shim is not necessary.

ARM64 - CA
==========

Everyone wants someone to do it but nobody is stepping up.
This particular CA will involve massive liability.
HORRID suggestions that this may need an x86 emulator on arm64.

Vendor co-operative to share responsibility?

Collect a known set of trusted keys - install all in the set but that is difficult
to organise and manage.

Pressurise the hardware vendors to do it? Customers need to push for it.

Trigger may be Windows arm64 server boxes or people shipping pre-installed
hardware.

Protecting the userspace (initramfs and rootfs)
===============================================

Cf https://lists.debian.org/debian-boot/2016/05/msg00145.html
but this is describing something more like Trusted Boot

Is it possible to build a generic initramfs and sign it?
- Needs to include local config files which practically can't be signed
  - generic config would work in many cases
  - /etc/crypttab can't be generic - can it?
    - and it can specify arbitrary commands to run :-(
      - How about passing arbitrary data to “interpreters” (ld.so, busybox, ...)?
  - udev rules also specify arbitrary commands
- Parsing of any config files not covered by signature needs to be robust against invalid content
- Easy cop-out: make the user add their own signing key