Re: [PATCH] imx: hab: add documentation about the required keys/certs

[Marek Vasut <marex@denx.de>]

On 5/8/24 9:23 AM, Claudius Heine wrote:
> Hi Marek,

Hi,

> On 2024-05-07 3:28 pm, Marek Vasut wrote:
>> On 5/7/24 3:06 PM, Claudius Heine wrote:
>>> For CST to find the certificates and keys for signing, some keys and
>>> certs need to be copied into the u-boot build directory.
>>
>> Make sure to CC "NXP i.MX U-Boot Team" , else NXP is not informed. Use 
>> scripts/get_maintainer to get the full list or just reuse the CC list 
>> from patches in this thread.
> 
> I send the patch with `--to-cmd scripts/get_maintainer.pl`, maybe I 
> should have used `--cc-cmd`, but that would not change the list of 
> recipients.

Should now be fixed in
[PATCH] ARM: imx: Add doc/imx/ to i.MX MAINTAINERS entry

>>> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt 
>>> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
>>> index ce1de659d8..42214df21a 100644
>>> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
>>> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
>>> @@ -144,6 +144,22 @@ The signing is activated by wrapping SPL and 
>>> fitImage sections into nxp-imx8mcst
>>>   etype, which is done automatically in 
>>> arch/arm/dts/imx8m{m,n,p,q}-u-boot.dtsi
>>>   in case CONFIG_IMX_HAB Kconfig symbol is enabled.
>>> +Per default the HAB keys and certificates need to be located in the 
>>> build
>>> +directory, this means copying the following files from the HAB keys 
>>> directory
>>> +flat (e.g. removing the `keys` and `cert` subdirectory) into the 
>>> u-boot build
>>> +directory for the CST Code Signing Tool to locate them:
>>
>> Do symlink(s) work too ?
> 
> I have not tested it, but I don't see any reason why it would not. I 
> also don't see a reason for mentioning it. I want to keep it simple, if 
> the dev whats to do things differently, they are free to do so.

"
Per default the HAB keys and certificates need to be located in the 
build directory, this means {+creating a symbolic link or +}copying the 
following...
"

Please test it and add it in V2 if it works, I think symlink is better 
than bluntly copying files around, esp. for crypto material.

>>> +- `crts/SRK_1_2_3_4_table.bin`
>>> +- `crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem`
>>> +- `keys/CSF1_1_sha256_4096_65537_v3_usr_key.pem`
>>> +- `crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem`
>>> +- `keys/IMG1_1_sha256_4096_65537_v3_usr_key.pem`
>>> +- `keys/key_pass.txt`
>>> +
>>> +The paths to the SRK table and the certificates can be modified via 
>>> changes to
>>> +the nxp_imx8mcst device tree node
>>
>> "nodes", plural, there are two, one for SPL and one for fitImage.
> 
> Well, I was thinking here more generally about the node type and was 
> assuming that the person reading this knows how many they have of that 
> type. But I can add a `s` in v2.

Use "node(s)" which covers both options.

>> It would be good to mention the DT properties which govern the crypto 
>> material paths -- nxp,srk-table, nxp,csf-crt, nxp,img-crt -- somewhere 
>> around this sentence.
> 
> This is something that should be documented with the changes where that 
> code was added, IMO. I only documented here what I found out and have 
> used myself, I haven't used those.
> 
> I would be interested in reading how to best overwrite those paths and 
> the image structured from board u-boot.dtsi files myself.
> 
> If you want to can pickup my patch and integrate it into your series and 
> extend it.

I'll keep it in mind for V3.