Bug 9878

There is an existing layer called meta-measuered [1] which provides some of this, there is also some work in Ostro-os that provides signed packages (or blobs), one of the problems with Grub v2 is that it's a GPLv3 Licence.

This may end up being an enhancement that generates additional enhancements, I am not sure this is for 2.2 timeframe, so moving it to 2.3

[1] https://layers.openembedded.org/layerindex/branch/master/layer/meta-measured/

Is the request to enable exactly the described way of doing secure boot, or some kind of secure boot? Do you want to use measured boot?

I am asking because Ostro uses a different kind of signed UEFI boot. Talk with Mikko and/or Igor if you are interested.

Also related: do you need integrity protection of the rootfs? This can be done either file-based (IMA/EVM, as in meta-intel-iot-security/meta-integrity) or block-based (for example, dm-crypt, dm-integrity or dm-verity). That also has implications for the update mechanism.

Here's an introduction to IMA/EVM, which contains a comparison against dm-verity and dm-integrity:

http://events.linuxfoundation.org/sites/events/files/slides/Integrity_Protection_LinuxCon_Europe_2013_0.pdf

dm-verity is only suitable for read-only partitions and thus
incompatible with swupd, but seems to have better performance than the other methods. It's used in Android.

dm-integrity and dm-crypt both could work, but the performance in that
comparison was even worse than IMA/EVM.

I'm curious about ISO format.
I thought that nowadays it was almost a relic, when it comes to booting a machine.
What's the use case?

About the combo EFI binary used in Ostro vs the multi-stage EFI loading:
one benefit of the single binary is that it relies solely on the EFI BIOS for authenticating and loading into memory everything that is needed up to and included the initramfs.

WRT choosing the protection method for the rootfs, I would also like to add that it should be considered if offline attacks (with the device unpowered) are expected or not - iow are there an hostile environment and/or user?
Ex: digibox implementing DRM decoding.

Cal, how do you intend to address the "signed packages" part of the feature request?

Presumably the requirement is for the kernel to only load trusted files (kernel modules, executables, data files, etc.).

I haven't decided yet - I only put in a time estimate because I keep getting bug cleanup requests and this bug was missing an estimate.

I have really only just begun looking into this - what options we have available for securely booting (UEFI secure boot, measured boot, trusted boot), and looking at what has already been done (such as the above meta-measured, and Ostro's secure boot docs), and have not started any implementation.

I have been working on taking the single binary approach from refkit and integrating it into meta-intel. See here: https://lists.yoctoproject.org/pipermail/meta-intel/2017-July/004821.html

This allows you to have a kernel, initramfs, and command line built into a single binary. For secure boot, you then just need to sign it with the keys that you would be embedding into the firmware. See do_uefiapp_sign here: https://lists.yoctoproject.org/pipermail/meta-intel/2017-July/004823.html

I'm also wanting to add another option using shim + systemd-boot, similar to what Windriver is doing here: https://github.com/jiazhang0/meta-efi-secure-boot

The single blob method is complete. Thanks Patrick, Mikko, and others for the help. The other methods using the real systemd-boot bootloader is being split into its own bug, as that will require more investigation to do correctly.