[PATCH v2 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing

Tim Harvey tharvey at gateworks.com
Thu May 16 00:31:30 CEST 2024 

On Tue, May 14, 2024 at 1:58 PM Marek Vasut <marex at denx.de> wrote:
>
> On 5/14/24 8:34 PM, Tim Harvey wrote:
>
> Hi,
>
> >> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> index e16e5410bd9..ce1de659d8c 100644
> >> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> @@ -121,6 +121,9 @@ build configuration:
> >>   - Defconfig:
> >>
> >>     CONFIG_IMX_HAB=y
> >> +  CONFIG_FSL_CAAM=y
> >> +  CONFIG_ARCH_MISC_INIT=y
> >> +  CONFIG_SPL_CRYPTO=y
> >>
> >
> > Hi Marek,
> >
> > Thanks for wrapping the dts bits with a config item.
> >
> > Is there any other reason to build with CONFIG_IMX_HAB than to use a
> > signed image? I see that there are several ARCH_MX6 and ARCH_MX7
> > configs that have this enabled (not ARCH_IMX8M so this certainly
> > doesn't break anything) and I'm not sure what the value of that is.
>
> I think those few either enabled in preemptively in anticipation of
> possibly using HAB, or are wrong. I suspect it should be disabled for
> those, as it only adds to the board boot time and I am not even sure if
> those machines would boot correctly.
>
> Francesco, maybe you do have MX7 Colibri ?
>
> > I notice that FSL_CAAM is selected when you select IMX_HAB... is there
> > any reason why ARCH_MISC_INIT and SPL_CRYPTO should not be selected by
> > IMX_HAB as well (future patch perhaps)?
>
> ARCH_MISC_INIT should be selected by SoC Kconfig on MX7 and maybe CAAM
> on MX8M I think . As for SPL_CRYPTO, that should be selected by
> SPL_FSL_CAAM I think.
>
> >>   - Kconfig:
> >>
> >
> > We definitely need to describe the additional requirements here. Maybe
> > something like:
> >
> > - Tools:
> > cst - NXP code-signing-tool (eg apt install imx-code-signing-tool)
> >
> > - Files: (created with NXP IMX_CST_TOOL)
> > SRK_1_2_3_4_table.bin (specified by nxp,srk-table node): fuse table
> > CSF1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,csf-crt node): CSF_KEY
> > IMG1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,img-crt node): IMG_KEY
> >
> > The following works fine for me on v2024.01
> > export CST_DIR=/usr/src/nxp/cst-3.3.2/
> > export CSF_KEY=$CST_DIR/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> > export IMG_KEY=$CST_DIR/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> > export SRK_TABLE=$CST_DIR/crts/SRK_1_2_3_4_table.bin
> > export PATH=$CST_DIR/linux64/bin:$PATH
> > make && /bin/sh doc/imx/habv4/csf_examples/mx8m/csf.sh
> >
> > But with the above defines and your series this fails:
> > ln -sf $SRK_TABLE SRK_1_2_3_4_table.bin
> > ln -sf $CSF_KEY CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> > ln -sf $IMG_KEY IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> > make
> >    BINMAN  .binman_stamp
> > Wrote map file './image.map' to show errors
> > binman: Error 1 running 'cst -i
> > ./nxp.csf-config-txt.section.nxp-imx8mcst at 0 -o
> > ./nxp.csf-output-blob.section.nxp-imx8mcst at 0': Error:
> > Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
> > 0:error:02001002:system library:fopen:No such file or
> > directory:crypto/bio/bss_file.c:288:fopen('IMG1_1_sha256_4096_65537_v3_usr_key.
> > pem','r')
> > 0:error:20074002:BIO routines:file_ctrl:system lib:crypto/bio/bss_file.c:290:
> >
> > make: *** [Makefile:1126: .binman_stamp] Error 1
> >
> > So how is it that the default for nxp,img-crt
> > IMG1_1_sha256_4096_65537_v3_usr_crt.pem is now looking for
> > IMG1_1_sha256_4096_65537_v3_usr_key? It fails also if I cp the files
> > vs ln them.
> >
> > So what am I missing here?
>
> I think CST is using both the certificate and the key files. Try and run
> strace on the CST to test that:
>
> $ strace cst -i ./nxp.csf-config-txt.section.nxp-imx8mcst at 0 -o
> ./nxp.csf-output-blob.section.nxp-imx8mcst at 0

Hi Marek,

(this is a resend... apologies if its a duplicate. I got some strange
bounce that mime types were included so I'm resending with the otuput
of strace cliped out)

strace was a good idea and showed me what was going on.

The previous documentation stated to pass your keys via env vars that
were full paths to key certificates. Using strace shows me that it
will use the directory the KEY certificate is in and try to open up
../keys/*_usr_key.pem if the key path is specified. So apparently the
'File' in the CST config file is used indirectly. Pointing to the
usr_key.pem isn't enough either by the way, it seems to need both of
these:

so if I hack the path to my certs in like this it works:diff --git
a/tools/binman/etype/nxp_imx8mcst.py
b/tools/binman/etype/nxp_imx8mcst.py
index 132127ad4827..b432200960df 100644
--- a/tools/binman/etype/nxp_imx8mcst.py
+++ b/tools/binman/etype/nxp_imx8mcst.py
@@ -67,10 +67,11 @@ class Entry_nxp_imx8mcst(Entry_mkimage):

     def ReadNode(self):
         super().ReadNode()
+        self.certpath =3D '/usr/src/nxp/cst-3.3.2/crts/';
         self.loader_address =3D fdt_util.GetInt(self._node, 'nxp,loader-ad=
dress')
         self.srk_table =3D fdt_util.GetString(self._node,
'nxp,srk-table', 'SRK_1_2_3_4_table.bin')
-        self.csf_crt =3D fdt_util.GetString(self._node, 'nxp,csf-crt',
'CSF1_1_sha256_4096_65537_v3_usr_crt.pem')
-        self.img_crt =3D fdt_util.GetString(self._node, 'nxp,img-crt',
'IMG1_1_sha256_4096_65537_v3_usr_crt.pem')
+        self.csf_crt =3D fdt_util.GetString(self._node, 'nxp,csf-crt',
self.certpath + '/CSF1_1_sha256_4096_65537_v3_usr_crt.pem')
+        self.img_crt =3D fdt_util.GetString(self._node, 'nxp,img-crt',
self.certpath + '/IMG1_1_sha256_4096_65537_v3_usr_crt.pem')
         self.unlock =3D fdt_util.GetBool(self._node, 'nxp,unlock')
         self.ReadEntries()

$ make -j8
  BINMAN  .binman_stamp
  OFCHK   .config

Strace indicatest the following with the above patch:
openat(AT_FDCWD,
"/usr/src/nxp/cst-3.3.2/crts//IMG1_1_sha256_4096_65537_v3_usr_crt.pem",
O_RDONLY)
...
openat(AT_FDCWD,
"/usr/src/nxp/cst-3.3.2/keys//IMG1_1_sha256_4096_65537_v3_usr_key.pem",
O_RDONLY)
^^^ look how it sneakily changes the PATH!

And without the above patch using a key file without a path:
openat(AT_FDCWD, "IMG1_1_sha256_4096_65537_v3_usr_crt.pem", O_RDONLY)
...
openat(AT_FDCWD, "IMG1_1_sha256_4096_65537_v3_usr_key.pem", O_RDONLY)
ENOENT (No such file or directory)
^^^ fails

Simply copying both usr_crt.pem and usr_key.pem to the build directory
still fails:
binman: Error 1 running 'cst -i
./nxp.csf-config-txt.section.nxp-imx8mcst at 0 -o
./nxp.csf-output-blob.section.nxp-imx8mcst at 0': Error:
Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
0:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
decrypt:crypto/evp/evp_enc.c:612:
0:error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal
error:crypto/pkcs12/p12_decr.c:62:
0:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe
crypt error:crypto/pkcs12/p12_decr.c:93:
0:error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1
lib:crypto/pem/pem_pkey.c:88:

Do you not run into this and if not is it because you have put full
paths in the dtsi overriding the defaults I'm using? Maybe this has
something to do with how my keys were generated or the version of cst
I'm using or maybe we just need to also add a directory which can be
symlinked to or something.

Another thing that I'm seeing is that this leaves a bunch of turd files around:
        cfg-out.section.nxp-imx8mcst at 0.nxp-imx8mimage
        cfg-out.section.nxp-imx8mimage
        input.section.nxp-imx8mcst at 0
        input.section.nxp-imx8mcst at 0.nxp-imx8mimage
        input.section.nxp-imx8mimage
        nxp.csf-config-txt.section.nxp-imx8mcst at 0
        nxp.cst-input-data.section.nxp-imx8mcst at 0
        nxp.imx8mimage.cfg.section.nxp-imx8mcst at 0.nxp-imx8mimage
        nxp.imx8mimage.cfg.section.nxp-imx8mimage

These intermediate files should be cleaned up after signing is complete.

Best Regards,

Tim

More information about the U-Boot mailing list