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

Re: [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@linux.vnet.ibm.com>
> To: openembedded-core@lists.openembedded.org
> Cc: joel@jms.id.au, andrew@aj.id.au, openbmc@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
>

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

[Klaus Heinrich Kiwi]

On 3/7/2021 11:51 PM, Dan Zhang wrote:
> Hi Klaus,

Hi Dan - sorry, your reply went under my radar last week!

> 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.

Thanks for the suggestion, however, I'm a bit hesitant with this change,
since for U-Boot the creation/support for the fitImage uImage needs
to be set in the u-boot config, so unlike the kernel I don't think
we could simply enable it on the machine.conf and expect it to work.

I'm about to send the patches below as a proper submission to
openembedded-devel, and I'll continue cross-posting to the openbmc
list. However, please feel free to answer with you suggestions and
copy the openembedded mailing-list as well.

Thanks!

  -Klaus




-- 
Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>

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

[Dan Zhang]

Hi Kaus,
What's my suggestion essentially is add a configuration i.e.
DO_UBOOT_SIGN to allow users only create a "signable" fit-image, but
sign later.

in the code
+ uboot_fitimage_assemble() {
...
+       #
+       # Sign the U-boot FIT image and add public key to SPL dtb
+       #
        if [ "x${DO_UBOOT_SIGN}" = "x1" ] ; then
+       ${UBOOT_MKIMAGE_SIGN} \
+               ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if
len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
+               -F -k "${UBOOT_SIGN_KEYDIR}" \
+               -K "${spl_dtb}" \
+               -r ${uboot_bin} \
+               ${UBOOT_MKIMAGE_SIGN_ARGS}
       fi
}




On Mon, Mar 15, 2021 at 9:47 AM Klaus Heinrich Kiwi
<klaus@linux.vnet.ibm.com> wrote:
>
>
>
> On 3/7/2021 11:51 PM, Dan Zhang wrote:
> > Hi Klaus,
>
> Hi Dan - sorry, your reply went under my radar last week!
>
> > 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.
>
> Thanks for the suggestion, however, I'm a bit hesitant with this change,
> since for U-Boot the creation/support for the fitImage uImage needs
> to be set in the u-boot config, so unlike the kernel I don't think
> we could simply enable it on the machine.conf and expect it to work.
>
> I'm about to send the patches below as a proper submission to
> openembedded-devel, and I'll continue cross-posting to the openbmc
> list. However, please feel free to answer with you suggestions and
> copy the openembedded mailing-list as well.
>
> Thanks!
>
>   -Klaus
>
>
>
>
> --
> Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>

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

[Klaus Heinrich Kiwi]

On 3/15/2021 6:31 PM, Dan Zhang wrote:
> Hi Kaus,

Hi Dan,


> What's my suggestion essentially is add a configuration i.e.
> DO_UBOOT_SIGN to allow users only create a "signable" fit-image, but
> sign later.
> 
> in the code
> + uboot_fitimage_assemble() {
> ...
> +       #
> +       # Sign the U-boot FIT image and add public key to SPL dtb
> +       #
>          if [ "x${DO_UBOOT_SIGN}" = "x1" ] ; then
> +       ${UBOOT_MKIMAGE_SIGN} \
> +               ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if
> len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
> +               -F -k "${UBOOT_SIGN_KEYDIR}" \
> +               -K "${spl_dtb}" \
> +               -r ${uboot_bin} \
> +               ${UBOOT_MKIMAGE_SIGN_ARGS}
>         fi
> }
> 

Yes, thanks for the suggestion. As I said, I'm a bit hesitant since the
semantics for creating a Kernel fitImage (i.e., setting KERNEL_CLASSES
and KERNEL_IMAGETYPES) is essentially non-existent for U-Boot.

I'll work on your suggestion, but I think we should use something like
UBOOT_ENABLE_FITIMAGE = "1" - creates the U-Boot fitImage
UBOOT_FITIMAGE_% - variables that control the fitImage creation
SPL_SIGN_ENABLE = "1" signs the U-boot fitImage
SPL_MKIMAGE_% - variables that control the U-boot fitImage signing

That way I guess the variables are used in a similar way as the kernel
fitImage scenario.

Thanks!

  -Klaus

-- 
Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>

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

[Klaus Heinrich Kiwi]

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