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

[Gaurav Jain <gaurav.jain@nxp.com>]

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.
To debug more, can you run hash command with HASH_VERIFY.

Regards
Gaurav Jain

> -----Original Message-----
> From: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>
> Sent: Friday, July 15, 2022 7:04 PM
> To: Gaurav Jain <gaurav.jain@nxp.com>
> Cc: u-boot@lists.denx.de; festevam@denx.de; sbabic@denx.de; Michael
> Walle <michael@walle.cc>; Tommaso Merciai
> <tommaso.merciai@amarulasolutions.com>; Michael Trimarchi
> <michael@amarulasolutions.com>; Marek Vasut <marex@denx.de>; Simon
> Glass <sjg@chromium.org>; Patrick Delaunay
> <patrick.delaunay@foss.st.com>; Stefan Roese <sr@denx.de>; Horia Geanta
> <horia.geanta@nxp.com>; Pankaj Gupta <pankaj.gupta@nxp.com>; Varun
> Sethi <V.Sethi@nxp.com>; Ye Li <ye.li@nxp.com>; dl-uboot-imx <uboot-
> imx@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@lists.denx.de> On Behalf Of Gaurav Jain
> > Sent: Friday, July 15, 2022 2:56 PM
> > To: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>
> > Cc: u-boot@lists.denx.de; festevam@denx.de; sbabic@denx.de; Michael
> > Walle <michael@walle.cc>; Tommaso Merciai
> > <tommaso.merciai@amarulasolutions.com>;
> > Michael Trimarchi <michael@amarulasolutions.com>; Marek Vasut
> > <marex@denx.de>; Simon Glass <sjg@chromium.org>; Patrick Delaunay
> > <patrick.delaunay@foss.st.com>; Stefan Roese <sr@denx.de>; Horia
> > Geanta <horia.geanta@nxp.com>; Pankaj Gupta <pankaj.gupta@nxp.com>;
> > Varun Sethi <V.Sethi@nxp.com>; Ye Li <ye.li@nxp.com>; dl- uboot-imx
> > <uboot-imx@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&amp;sdata=Dwe%2FOgeLeH
> mWD7tKcmmJbV
> > %2F0D5cOZvH3kpCx%2FO%2FvMRg%3D&amp;reserved=0
> > gaurav.jain@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@leica-geosystems.com>
> > > Sent: Friday, July 15, 2022 6:11 PM
> > > To: Gaurav Jain <gaurav.jain@nxp.com>
> > > Cc: u-boot@lists.denx.de; festevam@denx.de; sbabic@denx.de; Michael
> > > Walle <michael@walle.cc>; Tommaso Merciai
> > > <tommaso.merciai@amarulasolutions.com>; Michael Trimarchi
> > > <michael@amarulasolutions.com>; Marek Vasut <marex@denx.de>;
> Simon
> > > Glass <sjg@chromium.org>; Patrick Delaunay
> > > <patrick.delaunay@foss.st.com>; Stefan Roese <sr@denx.de>; Horia
> > > Geanta <horia.geanta@nxp.com>; Pankaj Gupta
> <pankaj.gupta@nxp.com>;
> > > Varun Sethi <V.Sethi@nxp.com>; Ye Li <ye.li@nxp.com>; dl-uboot-imx
> > > <uboot- imx@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@30280000 with servicing (60s timeout)
> > > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > > Loading Environment from MMC... *** Warning - bad CRC, using default
> > > environment
> > >
> > > In:    serial@30890000
> > > Out:   serial@30890000
> > > Err:   serial@30890000
> > > SEC0:  RNG instantiated
> > > Net:   eth0: ethernet@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