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

Fri Jul 15 14:56:00 CEST 2022

Hello Andrey

There is a patch in review related caam hash.
Please check if it fixes your problem.
http://patchwork.ozlabs.org/project/uboot/patch/20220616101009.809953-1-gaurav.jain@nxp.com/

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