[oe-core][RFC 0/3] u-boot: Support SPL Verified Boot

[Dan Zhang]

Hi Klaus,

Thank you very much for providing this solution to build and sign
u-boot fit-image.

I have one suggestion: decouple the U-Boot fit build and signing.

UBOOT_FIT ==> Create the uboot fit-image (essentially all your
proposal did, except the latest sign step in uboot_fit_assemble())
SPL_SIGN_ENABLE ==> create the uboot fit-image, also sign it.

This similar to kernel_fit means create the kernel fitimage, while
UBOOT_SIGN_ENABLE means sign it.

This will allow the user to use a simple script to sign an unsigned
image with any key, w/o need to be able to tweak the recipe and
rebuild the image.
i.e. the manufacturing team, the testing team.

BRs
Dan Zhang

> From: Klaus Heinrich Kiwi <klaus at linux.vnet.ibm.com>
> To: openembedded-core at lists.openembedded.org
> Cc: joel at jms.id.au, andrew at aj.id.au, openbmc at lists.ozlabs.org
> Bcc:
> Date: Sat,  6 Mar 2021 08:28:19 -0300
> Subject: [oe-core][RFC 0/3] u-boot: Support SPL Verified Boot
> This patch series aims at extending U-Boot's verified boot support to
> also include SPL signing.
>
> The proposal is to some of the infrastructure (variables, functions)
> used to sign the Kernel FitImage to more common locations, and then
> essentially duplicate the method currently used to sign the Kernel
> fitImage to also sign the U-Boot fitImage.
>
> In the UBOOT_SIGN_ENABLE = "1" scenario, nothing really changes: The
> Kernel fitImage is created, then signed, and the pubkey is added to
> u-boot.dtb which is concatenated with the u-boot-nodtb.bin to create the
> u-boot final image.
>
> In case SPL_SIGN_ENABLE = "1", The U-Boot PN will take care of (re-)
> creating the U-Boot fitImage (using custom .its script) after compile,
> sign it, and contatenate the u-boot-spl.dtb (with the public key) with
> u-boot-spl-nodtb.bin to create the final U-Boot SPl on deploy.
>
> In case both UBOOT_SIGN_ENABLE and SPL_SIGN_ENABLE are set, the Kernel
> PN will take care of creating and signing the U-Boot fitImage (becase we
> need to also sign the FDT image containing the Kernel pubkey), and take
> care of deploying it.
>
> I tested all three scenarios using OpenBMC upstream, and although there
> might be some areas of improvement (like deploying the new binaries and
> symlinks with more useful names), it appears to work well.
>
> One caveat is that when moving between the scenarios above, the user
> might need to remove the tmp/ directory, since there could be a
> collision for some of the files deployed into the images directory,
> since the configuration may determine which PN does that.
>
> Reviews, thoughts and comments are very very welcome,
>
> Thanks,
>
>  -Klaus
>