Hi Grant,
> 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.
>
This is exactly the reason i mentioned this on my first mail.
"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)".
s/minor adjustments/Your option #2/
I was wondering how hard/acceptable is to do option #2
> 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.
>
Thanks
/Ilias
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
