On Tue, May 14, 2024 at 1:58 PM Marek Vasut <ma...@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@0 -o
> > ./nxp.csf-output-blob.section.nxp-imx8mcst@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@0 -o
> ./nxp.csf-output-blob.section.nxp-imx8mcst@0

Hi Marek,

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 = '/usr/src/nxp/cst-3.3.2/crts/';
         self.loader_address = fdt_util.GetInt(self._node, 'nxp,loader-address')
         self.srk_table = fdt_util.GetString(self._node,
'nxp,srk-table', 'SRK_1_2_3_4_table.bin')
-        self.csf_crt = fdt_util.GetString(self._node, 'nxp,csf-crt',
'CSF1_1_sha256_4096_65537_v3_usr_crt.pem')
-        self.img_crt = fdt_util.GetString(self._node, 'nxp,img-crt',
'IMG1_1_sha256_4096_65537_v3_usr_crt.pem')
+        self.csf_crt = fdt_util.GetString(self._node, 'nxp,csf-crt',
self.certpath + '/CSF1_1_sha256_4096_65537_v3_usr_crt.pem')
+        self.img_crt = fdt_util.GetString(self._node, 'nxp,img-crt',
self.certpath + '/IMG1_1_sha256_4096_65537_v3_usr_crt.pem')
         self.unlock = fdt_util.GetBool(self._node, 'nxp,unlock')
         self.ReadEntries()

$ make -j8
  BINMAN  .binman_stamp
  OFCHK   .config

Here is a snippet of strace with the patch above:
openat(AT_FDCWD,
"/usr/src/nxp/cst-3.3.2/crts//IMG1_1_sha256_4096_65537_v3_usr_crt.pem",
O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=7012, ...}) = 0
read(6, "Certificate:\n    Data:\n        V"..., 4096) = 4096
read(6, "31:3d:64:30:11:32:1d:ab:15:\n    "..., 4096) = 2916
close(6)                                = 0
openat(AT_FDCWD,
"/usr/src/nxp/cst-3.3.2/keys//IMG1_1_sha256_4096_65537_v3_usr_key.pem",
O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0600, st_size=3414, ...}) = 0
read(6, "-----BEGIN ENCRYPTED PRIVATE KEY"..., 4096) = 3414

And a snippet at the same part without the patch above:
openat(AT_FDCWD, "IMG1_1_sha256_4096_65537_v3_usr_crt.pem", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=7012, ...}) = 0
read(6, "Certificate:\n    Data:\n        V"..., 4096) = 4096
read(6, "31:3d:64:30:11:32:1d:ab:15:\n    "..., 4096) = 2916
close(6)                                = 0
openat(AT_FDCWD, "IMG1_1_sha256_4096_65537_v3_usr_key.pem", O_RDONLY)
= -1 ENOENT (No such file or directory)
write(2, "Error: Cannot open key file IMG1"..., 68
Error: Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
) = 68
write(2, "0:error:02001002:system library:"...,
1430: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')

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:
$ git status
On branch cst
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        cfg-out.section.nxp-imx8m...@0.nxp-imx8mimage
        cfg-out.section.nxp-imx8mimage
        input.section.nxp-imx8mcst@0
        input.section.nxp-imx8m...@0.nxp-imx8mimage
        input.section.nxp-imx8mimage
        nxp.csf-config-txt.section.nxp-imx8mcst@0
        nxp.cst-input-data.section.nxp-imx8mcst@0
        nxp.imx8mimage.cfg.section.nxp-imx8m...@0.nxp-imx8mimage
        nxp.imx8mimage.cfg.section.nxp-imx8mimage

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

Best Regards,

Tim

Reply via email to