[EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series with CAAM enabled

Peng Fan peng.fan at oss.nxp.com
Fri Oct 14 03:00:49 CEST 2022 


On 7/15/2022 11:06 PM, ZHIZHIKIN Andrey wrote:
> Hello Gaurav,
> 
> Cc: Tom here for integration points.
> 
>> -----Original Message-----
>> From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Gaurav Jain
>> Sent: Friday, July 15, 2022 4:01 PM
>> To: ZHIZHIKIN Andrey <andrey.zhizhikin at leica-geosystems.com>
>> Cc: u-boot at lists.denx.de; festevam at denx.de; sbabic at denx.de; Michael Walle
>> <michael at walle.cc>; Tommaso Merciai <tommaso.merciai at amarulasolutions.com>;
>> Michael Trimarchi <michael at amarulasolutions.com>; Marek Vasut <marex at denx.de>;
>> Simon Glass <sjg at chromium.org>; Patrick Delaunay <patrick.delaunay at foss.st.com>;
>> Stefan Roese <sr at denx.de>; Horia Geanta <horia.geanta at nxp.com>; Pankaj Gupta
>> <pankaj.gupta at nxp.com>; Varun Sethi <V.Sethi at nxp.com>; Ye Li <ye.li at nxp.com>; dl-
>> uboot-imx <uboot-imx at nxp.com>
>> Subject: RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series
>> with CAAM enabled
>>
>> Hello Andrey
>>
>> Right now I am not sure what could cause the issue.
>> As per our previous discussions, JR0 can not be used in uboot, so you need to
>> mark it as disabled until kernel device tree is not sync.
> 
> Actually, I've given this a try by setting `status = "disabled"` in sec_jr0 node,
> and then the hash calculation was working again!

Did you enable optee? If disabling sec_jr0 to make it work, i think 
there is issue somewhere.

With optee enabled, optee will take JR0. If optee not enabled, JR0 could 
be used by U-Boot.

Regards,
Peng.

> 
> This has puzzled me a lot, since JR ID used to enqueue the SHA hashing descriptor
> is hard-coded to `0`, see the [1] for code reference. I was expecting that the
> call would fail but it somehow worked, perhaps by picking up the JR which is not
> disabled (JR1?)...
> 
> This is a bit that needs more explanation, perhaps you can shed some light here
> on how this JR assignments are working in case when nodes are enabled/disabled?
> 
> 
> Stefano/Tom,
> 
>  From what I can see, since patch from Fabio [2] is planned for inclusion to
> linux-5.20.y (see [3] for PR) - it might be that the SHA computation will stay
> broken on i.MX8M derivatives until v2022.10 at least, or the HW hash
> computations are replaced with SW alternative until the JR configuration is
> not synced into U-Boot.
> 
> Any advice on how to proceed here? I guess this would affect some people who are
> relying on FIT boot via `bootm`...
> 
>> To debug more, can you run hash command with HASH_VERIFY.
> 
> This did not solve the problem when JR0 node was still enabled, and had no effect
> when I disabled the node.
> 
>>
>> Regards
>> Gaurav Jain
>>
>>> -----Original Message-----
>>> From: ZHIZHIKIN Andrey <andrey.zhizhikin at leica-geosystems.com>
>>> Sent: Friday, July 15, 2022 7:04 PM
>>> To: Gaurav Jain <gaurav.jain at nxp.com>
>>> Cc: u-boot at lists.denx.de; festevam at denx.de; sbabic at denx.de; Michael
>>> Walle <michael at walle.cc>; Tommaso Merciai
>>> <tommaso.merciai at amarulasolutions.com>; Michael Trimarchi
>>> <michael at amarulasolutions.com>; Marek Vasut <marex at denx.de>; Simon
>>> Glass <sjg at chromium.org>; Patrick Delaunay
>>> <patrick.delaunay at foss.st.com>; Stefan Roese <sr at denx.de>; Horia Geanta
>>> <horia.geanta at nxp.com>; Pankaj Gupta <pankaj.gupta at nxp.com>; Varun
>>> Sethi <V.Sethi at nxp.com>; Ye Li <ye.li at nxp.com>; dl-uboot-imx <uboot-
>>> imx at nxp.com>
>>> Subject: RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m
>>> series with CAAM enabled
>>>
>>> Caution: EXT Email
>>>
>>> Hello Gaurav,
>>>
>>>> -----Original Message-----
>>>> From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Gaurav Jain
>>>> Sent: Friday, July 15, 2022 2:56 PM
>>>> To: ZHIZHIKIN Andrey <andrey.zhizhikin at leica-geosystems.com>
>>>> Cc: u-boot at lists.denx.de; festevam at denx.de; sbabic at denx.de; Michael
>>>> Walle <michael at walle.cc>; Tommaso Merciai
>>>> <tommaso.merciai at amarulasolutions.com>;
>>>> Michael Trimarchi <michael at amarulasolutions.com>; Marek Vasut
>>>> <marex at denx.de>; Simon Glass <sjg at chromium.org>; Patrick Delaunay
>>>> <patrick.delaunay at foss.st.com>; Stefan Roese <sr at denx.de>; Horia
>>>> Geanta <horia.geanta at nxp.com>; Pankaj Gupta <pankaj.gupta at nxp.com>;
>>>> Varun Sethi <V.Sethi at nxp.com>; Ye Li <ye.li at nxp.com>; dl- uboot-imx
>>>> <uboot-imx at nxp.com>
>>>> Subject: RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on
>>>> imx8m series with CAAM enabled
>>>>
>>>> Hello Andrey
>>>>
>>>> There is a patch in review related caam hash.
>>>> Please check if it fixes your problem.
>>>> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
>>>>
>>> work.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20220616101009.809953-
>>> 1-&a
>>>>
>>> mp;data=05%7C01%7Cgaurav.jain%40nxp.com%7C4e78116cfe2b4487fdc208
>>> da6666
>>>>
>>> aa79%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637934888408
>>> 633266%7
>>>>
>>> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
>>> TiI6Ik1
>>>>
>>> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Dwe%2FOgeLeH
>>> mWD7tKcmmJbV
>>>> %2F0D5cOZvH3kpCx%2FO%2FvMRg%3D&reserved=0
>>>> gaurav.jain at nxp.com/
>>>
>>> No, unfortunately this patch did not solve the issue, behavior is still the
>> same.
>>>
>>>>
>>>> Regards
>>>> Gaurav Jain
>>>>
>>>>> -----Original Message-----
>>>>> From: ZHIZHIKIN Andrey <andrey.zhizhikin at leica-geosystems.com>
>>>>> Sent: Friday, July 15, 2022 6:11 PM
>>>>> To: Gaurav Jain <gaurav.jain at nxp.com>
>>>>> Cc: u-boot at lists.denx.de; festevam at denx.de; sbabic at denx.de; Michael
>>>>> Walle <michael at walle.cc>; Tommaso Merciai
>>>>> <tommaso.merciai at amarulasolutions.com>; Michael Trimarchi
>>>>> <michael at amarulasolutions.com>; Marek Vasut <marex at denx.de>;
>>> Simon
>>>>> Glass <sjg at chromium.org>; Patrick Delaunay
>>>>> <patrick.delaunay at foss.st.com>; Stefan Roese <sr at denx.de>; Horia
>>>>> Geanta <horia.geanta at nxp.com>; Pankaj Gupta
>>> <pankaj.gupta at nxp.com>;
>>>>> Varun Sethi <V.Sethi at nxp.com>; Ye Li <ye.li at nxp.com>; dl-uboot-imx
>>>>> <uboot- imx at nxp.com>
>>>>> Subject: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on
>>>>> imx8m series with CAAM enabled
>>>>>
>>>>> Caution: EXT Email
>>>>>
>>>>> Hello Gaurav,
>>>>>
>>>>> In the new v2022.07, I've stumbled upon the issue with calculating
>>>>> the
>>>>> SHA256 of memory blocks with CAAM hashing. This causes the FIT image
>>>>> not to pass the hash validation, and also `sha256` command not operable.
>>>>>
>>>>> I'm also wondering if any i.MX8M-based board maintainers have seen
>>>>> the same issues at their end?
>>>>>
>>>>> I've made a small test executing the following command sequence
>>>>> (with corresponding serial output):
>>>>>
>>>>> U-Boot 2022.07 (Jul 15 2022 - 14:36:00 +0200)
>>>>>
>>>>> CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
>>>>> Reset cause: POR
>>>>> Model: FSL i.MX8MM EVK board
>>>>> DRAM:  2 GiB
>>>>> Core:  153 devices, 19 uclasses, devicetree: separate
>>>>> WDT:   Started watchdog at 30280000 with servicing (60s timeout)
>>>>> MMC:   FSL_SDHC: 1, FSL_SDHC: 2
>>>>> Loading Environment from MMC... *** Warning - bad CRC, using default
>>>>> environment
>>>>>
>>>>> In:    serial at 30890000
>>>>> Out:   serial at 30890000
>>>>> Err:   serial at 30890000
>>>>> SEC0:  RNG instantiated
>>>>> Net:   eth0: ethernet at 30be0000
>>>>> Hit any key to stop autoboot:  0
>>>>> u-boot=> mw.b ${kernel_addr_r} DE 100 u-boot=> md.b ${kernel_addr_r}
>>>>> 100
>>>>> 40480000: dededede dededede dededede dededede  ................
>>>>> 40480010: dededede dededede dededede dededede  ................
>>>>> 40480020: dededede dededede dededede dededede  ................
>>>>> 40480030: dededede dededede dededede dededede  ................
>>>>> 40480040: dededede dededede dededede dededede  ................
>>>>> 40480050: dededede dededede dededede dededede  ................
>>>>> 40480060: dededede dededede dededede dededede  ................
>>>>> 40480070: dededede dededede dededede dededede  ................
>>>>> 40480080: dededede dededede dededede dededede  ................
>>>>> 40480090: dededede dededede dededede dededede  ................
>>>>> 404800a0: dededede dededede dededede dededede  ................
>>>>> 404800b0: dededede dededede dededede dededede  ................
>>>>> 404800c0: dededede dededede dededede dededede  ................
>>>>> 404800d0: dededede dededede dededede dededede  ................
>>>>> 404800e0: dededede dededede dededede dededede  ................
>>>>> 404800f0: dededede dededede dededede dededede  ................
>>>>>
>>>>> u-boot=> hash sha256 ${kernel_addr_r} 100 CAAM was not setup
>>>>> properly or it is faulty
>>>>> sha256 for 40480000 ... 404800ff ==>
>>>>>
>>> 736372697074616464727d0a626f6f745f6566695f62696e6172793d6c6f6164
>>>>>
>>>>> Running `sha256` commands several times in a row also produces
>>>>> different Results, sometimes it comes out as all 0's.
>>>>>
>>>>> For comparison purposes, I've did similar on the desktop:
>>>>> $ while true ; do printf "\xDE"; done | dd of=./test_data bs=1
>>>>> count=256
>>>>> 256+0 records in
>>>>> 256+0 records out
>>>>> 256 bytes copied, 0.000484 s, 529 kB/s
>>>>>
>>>>> $ hexdump -C -v ./test_data
>>>>> 00000000  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 00000010  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 00000020  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 00000030  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 00000040  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 00000050  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 00000060  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 00000070  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 00000080  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 00000090  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 000000a0  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 000000b0  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 000000c0  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 000000d0  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 000000e0  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 000000f0  de de de de de de de de  de de de de de de de de
>>>>> |................|
>>>>> 00000100
>>>>>
>>>>> $ sha256sum ./test_data
>>>>>
>>> 8b11bcdc65d5f1af0fa1edfa7b5db089dba40d4e8d29b455295d58ab2b314e76
>>>>>   ./test_data
>>>>>
>>>>> As one can see, the SHA256 has a totally different value, with
>>>>> desktop produces a rather correct one.
>>>>>
>>>>> Since the CAAM is enabled per default for all i.MX8M derivatives,
>>>>> there is no way to target SHA hash calculations back to SW
>>>>> implementation, therefore it blocks a lot of people to boot FIT images
>>> that has `hash` nodes in them.
>>>>>
>>>>> Looking a bit deeper into why it fails, I saw that the JR used for
>>>>> hash calculations is hard-coded to `0` in run_descriptor_jr() call,
>>>>> which is now reserved in S-World for HAB operations. But changing it
>>>>> to `1` did not change the behavior, the SHA256 is still not calculated
>>> proper.
>>>>>
>>>>> Can you please advise how this can be solved?
>>>>>
>>>>> And more conceptually: why is SHA hashing now hardwired to HW CAAM
>>>>> module, while it was perfectly executed in SW via `lib/sha.c`?
>>>>>
>>>>> Thanks a lot!
>>>>>
>>>>> Regards,
>>>>> Andrey
>>>
>>> -- andrey
> 
> Thanks a lot!
> 
> -- andrey
> 
> Link: [1]: https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/crypto/fsl/jr.c#L372
> Link: [2]: https://lore.kernel.org/all/20220608170223.1536594-1-festevam@denx.de/
> Link: [3]: https://lore.kernel.org/all/20220709082951.15123-5-shawnguo@kernel.org/

More information about the U-Boot mailing list