On 31/05/2019 13:12, 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?
If the protocol (or an evolution of it) is proposed to be included in the UEFI spec, then I agree. However, if it remains a shim-only thing, then it should be left as part of Shim. g. > > 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. > > Cheers > > FF > > On Fri, 31 May 2019 at 13:52, Grant Likely <[email protected] > <mailto:[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] > <mailto:[email protected]> > > https://lists.linaro.org/mailman/listinfo/boot-architecture > > > _______________________________________________ > boot-architecture mailing list > [email protected] > <mailto:[email protected]> > https://lists.linaro.org/mailman/listinfo/boot-architecture > > > > -- > > François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ > T: +33.67221.6485 > [email protected] <mailto:[email protected]> | Skype: ffozog > > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
