9878 2016-07-05 09:53:11 +0000 feature request: secure boot layer 2017-07-20 18:10:47 +0000 1 1 7 Build System, Metadata & Runtime Other YP Layers layers unspecified Other Multiple RESOLVED FIXED High enhancement 2.4 M2 1 mei.yeen.ng california.l.sullivan bluelightning mikko.ylinen patrick.ohly poky.bs.watcher poky.watcher radzy randy.macleod sgw --- --- Don't know oldest_to_newest 63650 0 mei.yeen.ng 2016-07-05 09:53:11 +0000 It would be great to have a layer supporting UEFI secure boot (also known as verified boot). The layer enables any images to be build with - shim v0.8 as the first bootloader - grub v2.02~beta3 - generates signed kernel, grub, and shim with pesign - populate ISO and HDDIMG with signed packages 63774 1 sgw 2016-07-08 21:20:34 +0000 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/ 67885 2 patrick.ohly 2016-11-03 10:20:24 +0000 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. 67889 3 igor.stoppa 2016-11-03 10:37:36 +0000 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. 68463 4 patrick.ohly 2016-11-21 18:50:15 +0000 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.). 68464 5 california.l.sullivan 2016-11-21 19:02:25 +0000 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. 74942 6 california.l.sullivan 2017-07-11 21:42:08 +0000 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 75204 7 california.l.sullivan 2017-07-20 18:10:47 +0000 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.