On 24/05/2019 16:28, Ilias Apalodimas wrote:
Hello all,
Continuing the discussions we had on securing the boot flow and OS as much as possible, we came up with the following idea.
We are currently sorting out what's needed to add UEFI Secure Boot in U-Boot. This will cover the next payload (shim/grub2/shim depending on board needs).
In order to provide better overall security for the OS we'll need to at least verify DTB (if provided externally), initramfs and kernel modules.
- For the kernel modules we can use kernel module signing facilities [1 > 2. In case someone wants to provide an external DTB, we can use FIT
images
to secure that. The FIT images will contain the DTB(s) we need. Those will only be used if the authentication process succeeds. This will allow us to verify DTBs without introducing any new functionality to U-Boot.
The trouble with this scenario is it uses a different authentication scheme from the OS boot. OS boot would verify against the Secure boot DB/DBX variables, but the FIT image containing a new DTB uses an entirely different authentication path, and the platform needs a way to break into the boot flow early (before UEFI Boot Device Selection) to perform the custom DTB load step before choosing the kernel to boot. That might be too early to know which .dtb needs to be loaded.
I see two ways to handle this that fits with the Secure Boot authentication path:
Option 1: Leave it to the OS loader We could simply say that if the OS wants to replace the DTB, then it should take care of authentication itself within the OS loader (possibly the in-kernel UEFI stub) and install a replacement DTB in the configuration table before calling exit boot services. In this scenario, U-Boot doesn't authenticate the DTB at all.
In fact, Option 1 is pretty close to what is required for the initrd.
I wonder if it is possible to wrap the DTB with a PE/COFF so that the os loader can use load_image to authenticate and retrieve the data without actually executing the image. That would allow for the DTB & initrd to be authenticated in the same way as the kernel.
Option 2: Put a PE/COFF wrapper around the dtb The wrapper can be really simple. Little more than the following code: { bootservices.allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, EFI_RUNTIME_SERVICES_DATA, 1, &dtb_addr); memcpy() bootservices.install_configuration_table(dtb_guid, dtb_addr); }
This allows the DTB to be managed separately from the kernel (which may or may not be desired; depending on use-case), and it uses the same authentication scheme as for the OS loader. It would would on both Tianocore and U-Boot UEFI implementations. The dtb toolchain could be modified to use a stock wrapper. The same technique could even be used to load and apply dtb overlays. Downside is the wrapper would be architecture dependent
I think option 1 is pretty close to the approach used by stub, and I suspect it fits better into the deployment scenarios that would want to ship a DTB with the kernel. I would go down that path.
In either case, I'm now leaning toward the opinion that calling install_configuration_table() to change the dtb is the right thing to do. The DTB still gets exposed to the kernel in the same way, and it provides the option of firmware applying updates (ie. kernel command line) to the new dtb at ExitBootServices() time. It also acknowledges that the DTB used to boot the kernel isn't always the DTB used internally by U-Boot.
- We need to verify initramfs as well. This can be accomplished in various ways.
Packing kernel + initramfs or using dm-verity are the two obvious ones but we are open to suggestions.
Signing initrd images is pretty important I think the same options apply. What is currently being done in the x86 distro space?
This also makes the development process for LEDGE pretty clear. We'll have to add UEFI Secure Boot implementation on U-Boot *only* since the rest of the functionality can be achieved with the existing code (minor adjustments might be needed though).
What do you think?
[1] https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html
Thanks /Ilias _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture