UEFI Capsule Update support

Requirements:
Kernel 4.2 (or appropriate patching earlier kernels) for ESRT support (may require pstore, ESRT. ESRT looks smallish as a patch)
fwupdate (EFI Application for applying Capsule updates)
fwupdate/libfwup (Linux application and library to interface with fwupdate EFI app / EFI structures)
Patch libfwup to properly handle shim (paths appear RedHat specific)
Due to the finite size of ESP, provide a way for users to clean up old (applied) firmware updates.

Optional Requirements:
fwupd (daemon from rh to interface with fwupdate app as a user)

Process:
Option 1: A user installs a .deb file from the Ubuntu archive, which ships just the necessary capsule, in a suitable path (/opt/$vendor ?), and calls the fwupdate command in postinst.

Option 2: A user downloads a capsule update from a vendor (may be a fully-formed capsule or partial, as per specs), and runs the fwupdate command directly or uses an application shipped by Ubuntu to pick the right firmware update file for a supported device, as retrieved from the list of supported updates from libfwup.

$option would speak to fwupdate to check that Capsule updates are supported and that particular update is supported, and if so, select the update to be applied. If an update is to be applied, signify to the user they should reboot (/usr/share/update-notifier/notify-reboot-required).

fwupdate/libfwup uses the structures in EFI to verify the signature of the proposed update and to write a properly-named fwupdate-XYZ.cap file which will be read by the fwupdate EFI app on reboot. It then toggles a flag for fwupdate to know to attempt firmware updates when it is started. It finally sets up BootNext to start in fwupdate on the next boot only.

On boot in fwupdate, the fwupdate EFI app reads the ESRT to know what updates need to be applied; reads the files from disk and applies them (the actual UpdateCapsule calls, which may or may not trigger further signature verification of the Firmware Volume files contained in the Capsule itself (see EFI Capsule Specification, signature verification in DXE appears to be optional)). Once done, it calls ResetSystem for the system to boot back into usual BootOrder.

Implementation plan:
This should probably be done in three phases:

Phase 1: Manual use of fwupdate with capsules from vendor
Phase 2: Integration in Debian/Ubuntu packages
Phase 3: (Optional) Integrate with Device Drivers

Related links:
Windows UEFI Firmware Update Platform: http://www.microsoft.com/en-us/download/details.aspx?id=38405
EFI Capsule specification: http://www.intel.com/content/dam/doc/reference-guide/efi-capsule-specification.pdf
EFI Driver Execution Environment Core Interface Specification (DXE CIS) http://www.intel.com/content/dam/doc/reference-guide/efi-dxe-cis-v09.pdf
Ubuntu kernel 4.1 with ESRT patches: http://kernel.ubuntu.com/git/rtg/ubuntu-wily.git/log/?h=esrt
LKML: [PATCH 0/5] EFI capsule pstore support https://lkml.org/lkml/2013/10/16/327
LKML: [GIT PULL] EFI changes for v4.2 https://lkml.org/lkml/2015/5/31/105
Fwupdate: https://github.com/rhinstaller/fwupdate
fwupd (daemon to allow session software communicate): https://github.com/hughsie/fwupd

Work items:
Patch fwupdate (CLI) to handle shim correctly: DONE
Package/ship fwupdate command and EFI executable: DONE
Package/ship signed fwupdate EFI binary: DONE
MIR fwupdate: DONE

Work items for later:
Teach fwupdate (CLI) to do signature checking at the package/capsule level: TODO
Provide a method for clearing up applied firmware updates safely from fwupdate: TODO
Testing linux<->EFI integration: TODO
Testing cleanup: TODO
Hook up to .deb files postinst: TODO
Overload modaliases to understand GUIDs for firmware updates: TODO
Make use of modaliases to identify target devices for selecting firmware updates: TODO
Extend Device Drivers if necessary to do the right thing: TODO