FitImage signing with FIP enabled on STM32MP157C-DK2

[Yumasi]

Hi!

I am trying to have full secure booting on the stm32mp platform, using FIP and fitImage on a custom distribution built using Yocto with the meta-st-stm32mp layer.

I currently have a FIP containing u-boot booting on the board, that can then load and boot an unsigned fitImage.

I now want to enable fitImage signing. The signature verification in u-boot is enabled in u-boot's configuration, and u-boot devicetree has been extended to include a signature section, so that mkimage can insert the signing key for u-boot's to verify my fitImage.

The fitImage is signed with the key by setting the following variable in my machine configuration:

UBOOT_SIGN_ENABLE = "1"

I checked that the image is indeed signed, and that a u-boot devicetree containing the key is in my deploy directory (I disabled the use of the "u-boot" subfolder with a bbappend on u-boot-stm32mp recipe).

The issue comes from the final dtb included in u-boot´s binary, before the FIP generation by fiptool. By the end of the kernel signing process (which also insert the key in a devicetree to be used by u-boot), the devicetree containing the key is different than the one compiled due to the layer meta-st-stm32mp additions to u-boot's compile step (which compiles a dtb per enabled devicetree in the machine configuration, in addition to the one normally compiled by the base u-boot recipe from poky which is used by kernel-fitimage.bbclass when signing the kernel). The devicetree used when building the FIP is one of those devicetrees compiled due to the append on the compile step of u-boot by the ST layer, which means the FIP won't use at all the updated devicetree with the key necessary to verify fitImages.

To give you an exemple, here the relevant files in my deploy directory:

u-boot-mp1-2020.10.r1-r0.dtb  # The devicetree containing the key. The file name is in the variable UBOOT_DTB_IMAGE
u-boot-nodtb-stm32mp15.bin  # The uboot binary without a devicetree
u-boot-stm32mp157c-dk2-trusted.dtb  # The devicetree from the append on the compile/deploy steps, not containing the key, but that will end up in the FIP.

Is there something I am missing, or another way to achieve full secure boot with FIP ? Is this something that was not tested with the layer ?

I would be happy to give more information to get to the bottom of this.

Thanks in advance

--

Guillaume Pagnoux

[Olivier GALLIEN]

Hi @Yumasi​ ,

Thanks for your post.

Looks like interesting use case which would require some further guideline from our side.

I'm not personally comfortable with Yocto, so I need to contact few expert in order to help.

But in the meantime could you clarify the method you use to generate your custom image ?

Can you share the files you have modified in the layer ?

Thanks

Olivier

[Yumasi]

Hi @Community member​ ,

The image we build is based on Yocto's core-image class. The configuration for it to work on the stm32mp157c-dk2 is in a custom machine, named mp1, based on the files from the meta-st-stm32mp layer:

include conf/machine/include/st-machine-common-stm32mp.inc
include conf/machine/include/st-machine-providers-stm32mp.inc
 
# Define specific familly common machine name
MACHINEOVERRIDES .= ":stm32mp1common"
 
DEFAULTTUNE = "cortexa7thf-neon-vfpv4"
include conf/machine/include/tune-cortexa7.inc
 
BOOTSCHEME_LABELS += "trusted"
 
# =========================================================================
# boot device
# =========================================================================
# Define the boot device supported
BOOTDEVICE_LABELS += "sdcard"
 
MACHINE_FEATURES += " ${@bb.utils.contains_any('BOOTDEVICE_LABELS',  ['emmc', 'sdcard'], 'autoresize', '', d)} "
 
# =========================================================================
# Machine settings
# =========================================================================
# Define list of devicetree per board
STM32MP_DT_FILES_DK += "stm32mp157c-dk2"

We only want one partition that includes the kernel image, and we don't use syslinux:

# Do not generate ST's default partitions
ENABLE_PARTITIONS_IMAGE = "0"
ENABLE_FLASHLAYOUT_CONFIG = "0"
 
IMAGE_INSTALL += " \
        kernel-imagebootfs \
        "

From this, we have a uImage in our rootfs that can be successfully booted by the generated u-boot as the ssbl.

The fitImage and the fip containing u-boot is created by enabling the following features from the meta-st-stm32mp layer in our machine configuration:

MACHINE_FEATURES += "fit"
MACHINE_FEATURES += "fip"

Again, our image boots fine when using the generated fip and fitImage from this configuration.

We enable fitImage signing using poky's builtin feature:

UBOOT_SIGN_ENABLE = "1"
UBOOT_SIGN_KEYDIR = "${DEPLOY_DIR_IMAGE}" 
UBOOT_SIGN_KEYNAME = "ubootfit"
UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 0x1000"
 
# The signing process expects to find the kernel and u-boot in the deploy directory, 
# and will output the resulting binaries there as well, so we tell fip to find u-boot there.
FIP_DEPLOYDIR_UBOOT  ?= "${DEPLOY_DIR}/images/${MACHINE}" 

We have those appends to u-boot-stm32mp and linux-stm32mp in our layer to place u-boot's binary and the fitImage in the deploy directory:

do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"

Finally I made a patch for u-boot-stm32mp to enable signature verification in u-boot. It is added to the SRC_URI variable in the aforementioned bbappend on u-boot. The patch is attached to this post.

Thanks,

--

Guillaume