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
