On 5/31/19 2:12 PM, Francois Ozog wrote: > Can we just register the OS loader as a UEFI protocol (say LoadGrubImage, > LoadLinuxImage, LoadAndroidImage), which would do everything needed to > check the broader environment? > This becomes usable with both EDKII and U-Boot? > > LoadImage is used by <firmware> to securely load shim<arch>.efi > LoadGrubImage is used by shim<arch>.efi to securely load grub<arch>.efi > (check modules, config...) > LoadLinuxImage is used by grub<arch>.efi to securely load Linux environment > > If the protocols are not present, then a simple LoadImage is used.
What is the reasoning for your suggestion? I cannot see what you are missing in LoadImage(). With secure boot enabled LoadImage() will check the signature of any EFI binary including GRUB, Linux, and Shim. It is the task of the loaded application to verify any modules it loads afterwards. This functionality already exists, e.g. once the Linux Kernel is loaded it uses UEFI variables db and dbx to update the system keyring against which the modules are checked. The UEFI spec should be OS agnostic so having GRUB or Linux specific protocols implemented in U-Boot or EDK II makes no sense to me. Best regards Heinrich > > Cheers > > FF > > On Fri, 31 May 2019 at 13:52, Grant Likely <[email protected]> wrote: > >> >> >> 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. >>> >>> 1. 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. >> >> >>> 3. 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 >>> [email protected] >>> https://lists.linaro.org/mailman/listinfo/boot-architecture >>> >> _______________________________________________ >> boot-architecture mailing list >> [email protected] >> https://lists.linaro.org/mailman/listinfo/boot-architecture >> > > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
