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

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

[ZHIZHIKIN Andrey]

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

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

[Gaurav Jain]

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@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

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

[ZHIZHIKIN Andrey]

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.
> http://patchwork.ozlabs.org/project/uboot/patch/20220616101009.809953-1-
> 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

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

[Gaurav Jain]

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

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

[ZHIZHIKIN Andrey]

Hello Gaurav,

Cc: Tom here for integration points.

> -----Original Message-----
> From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Gaurav Jain
> Sent: Friday, July 15, 2022 4:01 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
> 
> 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!

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@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

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/

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

[Fabio Estevam]

Hi Andrey,

On Fri, Jul 15, 2022 at 12:06 PM ZHIZHIKIN Andrey
<andrey.zhizhikin@leica-geosystems.com> wrote:

> 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`...

I will send a patch syncing imx8mm.dtsi from linux-next.

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

[Gaurav Jain]

Hello Andrey

> -----Original Message-----
> From: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>
> Sent: Friday, July 15, 2022 8:36 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>; trini <trini@konsulko.com>
> Subject: RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m
> series with CAAM enabled
> 
> Caution: EXT Email
> 
> Hello Gaurav,
> 
> Cc: Tom here for integration points.
> 
> > -----Original Message-----
> > From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Gaurav Jain
> > Sent: Friday, July 15, 2022 4:01 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
> >
> > 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!

This is expected as caam driver will pick up the first jobring enabled in device tree.
> 
> 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?)...

Caam driver model approach was developed to initialize the caam based on jobring enabled in device tree.
If driver model is not enabled then hardcoded JR0 will be used.
> 
> 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?

See the code drivers/crypto/fsl/jr.c ,  function caam_jr_probe().
This function checks for enabled job ring and initialize caam.

Regards
Gaurav 
> 
> 
> 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@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%2Fp
> > > > atch
> > > >
> > >
> 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
> 
> Thanks a lot!
> 
> -- andrey
> 
> Link: [1]:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourc
> e.denx.de%2Fu-boot%2Fu-boot%2F-
> %2Fblob%2Fmaster%2Fdrivers%2Fcrypto%2Ffsl%2Fjr.c%23L372&amp;data=0
> 5%7C01%7Cgaurav.jain%40nxp.com%7C351b3fc4ae864c5e579a08da6673901
> 2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637934943776754
> 909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=G%
> 2FBsNqPCACQ5F8DoYgy7IOwgu1QZeUVei85gwKzhpaw%3D&amp;reserved=0
> Link: [2]:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.k
> ernel.org%2Fall%2F20220608170223.1536594-1-
> festevam%40denx.de%2F&amp;data=05%7C01%7Cgaurav.jain%40nxp.com%
> 7C351b3fc4ae864c5e579a08da66739012%7C686ea1d3bc2b4c6fa92cd99c5c3
> 01635%7C0%7C0%7C637934943776754909%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000%7C%7C%7C&amp;sdata=zQm7kQHuOyLfkfI2WFPJtl0YKtPhVFtUM
> s7BoCedGsY%3D&amp;reserved=0
> Link: [3]:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.k
> ernel.org%2Fall%2F20220709082951.15123-5-
> shawnguo%40kernel.org%2F&amp;data=05%7C01%7Cgaurav.jain%40nxp.co
> m%7C351b3fc4ae864c5e579a08da66739012%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C637934943776754909%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C&amp;sdata=geHpB6tnctt4dG5N8lhzlUJM31rj3T5b
> 9J8hkDgKVcc%3D&amp;reserved=0

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

[Rasmus Villemoes]

On 15/07/2022 14.40, ZHIZHIKIN Andrey wrote:
> 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)

This is still broken in v2022.10. Are there any plans to fix this?

Booting FIT images where image nodes are hashed with sha1 or sha256 on
imx8m boards is currently impossible.

Rasmus

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

[Fabio Estevam]

Hi Rasmus,

On Mon, Oct 10, 2022 at 11:07 AM Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:

> This is still broken in v2022.10. Are there any plans to fix this?

If I recall correctly the fix for this issue is to sync imx8m dts
files with Linux so that the following
commit can be in place:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.0&id=dc9c1ceb555ff661e6fc1081434600771f29657c

Marcel submitted some imx8m dtsi sync patches, which should address
this failure.

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

[Gaurav Jain]

Hi Fabio

Thanks for the patch information.
@Rasmus Villemoes I hope this fixed your problem?

Regards
Gaurav Jain

> -----Original Message-----
> From: Fabio Estevam <festevam@gmail.com>
> Sent: Monday, October 10, 2022 7:45 PM
> To: Rasmus Villemoes <rasmus.villemoes@prevas.dk>; Marcel Ziswiler
> <marcel.ziswiler@toradex.com>
> Cc: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>; Gaurav
> Jain <gaurav.jain@nxp.com>; 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] Re: [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m
> series with CAAM enabled
> 
> Caution: EXT Email
> 
> Hi Rasmus,
> 
> On Mon, Oct 10, 2022 at 11:07 AM Rasmus Villemoes
> <rasmus.villemoes@prevas.dk> wrote:
> 
> > This is still broken in v2022.10. Are there any plans to fix this?
> 
> If I recall correctly the fix for this issue is to sync imx8m dts files with Linux so
> that the following commit can be in place:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2F
> commit%2F%3Fh%3Dv6.0%26id%3Ddc9c1ceb555ff661e6fc1081434600771f29
> 657c&amp;data=05%7C01%7Cgaurav.jain%40nxp.com%7Ce5f346e2f2024b08
> 83ab08daaac9e5c7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
> 38010081361514213%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> C&amp;sdata=oEYSt8zYXlvu0mfmmop76Eshz0WKySE%2Buk6D3MKgpRM%3
> D&amp;reserved=0
> 
> Marcel submitted some imx8m dtsi sync patches, which should address this
> failure.

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

[Rasmus Villemoes]

On 13/10/2022 08.20, Gaurav Jain wrote:
> Hi Fabio
> 
> Thanks for the patch information.
> @Rasmus Villemoes I hope this fixed your problem?
> 

Sort of, kind of. I monkey-patched arch/arm/dts/imx8mp-u-boot.dtsi to
include that

+&sec_jr0 {
+       status = "disabled";
+};
+

because I don't want to do the much more invasive thing of sync'ing
imx8mp.dtsi proper with linux master. So yes, the pointers did lead me
to a local fix, and one that I can hopefully rip out again with the next
U-Boot release.

Rasmus

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

[Peng Fan]

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@lists.denx.de> On Behalf Of Gaurav Jain
>> Sent: Friday, July 15, 2022 4:01 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
>>
>> 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@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
> 
> 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/

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

[Rasmus Villemoes]

On 14/10/2022 03.00, Peng Fan wrote:
> 
>>> 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.

I can't speak for Andrey, but no, I don't enable/use optee on my imx8mp.

Rasmus

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

[ZHIZHIKIN Andrey]

Hello all,

> -----Original Message-----
> From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Rasmus Villemoes
> Sent: Friday, October 14, 2022 7:50 PM
> To: Peng Fan <peng.fan@oss.nxp.com>; ZHIZHIKIN Andrey <andrey.zhizhikin@leica-
> geosystems.com>; 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>; trini <trini@konsulko.com>
> Subject: Re: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series
> with CAAM enabled
> 
> On 14/10/2022 03.00, Peng Fan wrote:
> >
> >>> 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.
> 
> I can't speak for Andrey, but no, I don't enable/use optee on my imx8mp.

I also do not have an OP-TEE in my setup, but since upstream TF-A commit
77850c96f23b ("feat(plat/imx8m): do not release JR0 to NS if HAB is using
it") [1] this makes no difference, as JR0 would be permanently held in
S-World.

Downstream fork has the same implementation done in commit 961f90418874
("TEE-639 plat: imx8m: Do not release JR0 to NS if HAB is using it"), so it
is now consistent behavior across upstream and downstream.

This means that JR0 has to be permanently disabled in the DTB, with Kernel
being the first followed by the U-Boot sync.

This work has been already accomplished by Fabio in Kernel via commit
dc9c1ceb555f ("arm64: dts: imx8m: Disable job ring 0 nodes") [3], and sync'd
in for `imx8mm.dtsi` in commit 05996f350d48 ("imx8mm: Sync device tree with
linux-next 20220711") [4].

`imx8mp.dtsi` however was not sync'd in, so the JR0 disabling is left out. :(
This does explain why the SHA calculation are not operable for that SoC.

> 
> Rasmus

-- andrey

Link: [1]: http://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=77850c96f23bcdc76ecb0ecd27a982c00fde5d9d
Link: [2]: https://source.codeaurora.org/external/imx/imx-atf/commit/plat/imx/imx8m/imx8m_caam.c?id=961f904188746ce495af67a40f300f5b0bd50ca4
Link: [3]: https://github.com/torvalds/linux/commit/dc9c1ceb555ff661e6fc1081434600771f29657c
Link: [4]: https://source.denx.de/u-boot/u-boot/-/commit/05996f350d482d2a450173ce3340ee69c8f74ad4

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

[Fabio Estevam]

Hi Andrey,

On Fri, Oct 14, 2022 at 3:53 PM ZHIZHIKIN Andrey
<andrey.zhizhikin@leica-geosystems.com> wrote:

> `imx8mp.dtsi` however was not sync'd in, so the JR0 disabling is left out. :(
> This does explain why the SHA calculation are not operable for that SoC.

Marcel has submitted the dts sync patch:
https://lists.denx.de/pipermail/u-boot/2022-August/492834.html

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

[ZHIZHIKIN Andrey]

Hello Fabio,

> -----Original Message-----
> From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Fabio Estevam
> Sent: Friday, October 14, 2022 9:38 PM
> To: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>
> Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>; Peng Fan
> <peng.fan@oss.nxp.com>; Gaurav Jain <gaurav.jain@nxp.com>; 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>; trini <trini@konsulko.com>
> Subject: Re: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series
> with CAAM enabled
> 
> Hi Andrey,
> 
> On Fri, Oct 14, 2022 at 3:53 PM ZHIZHIKIN Andrey
> <andrey.zhizhikin@leica-geosystems.com> wrote:
> 
> > `imx8mp.dtsi` however was not sync'd in, so the JR0 disabling is left out. :(
> > This does explain why the SHA calculation are not operable for that SoC.
> 
> Marcel has submitted the dts sync patch:
> https://lists.denx.de/pipermail/u-boot/2022-August/492834.html

Yes, but this was not picked up... At least, I do not see it applied on the master.

From the entire series [1], the patch that shall solve the issue is [2], and it is
the one I do not see applied onto master.

Regards,
Andrey

Link: [1]: https://lore.kernel.org/u-boot/20220826183141.789236-1-marcel@ziswiler.com/
Link: [2]: https://lore.kernel.org/u-boot/20220826183141.789236-7-marcel@ziswiler.com/

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

[Fabio Estevam]

Hi Andrey,

On Sun, Oct 16, 2022 at 7:17 AM ZHIZHIKIN Andrey
<andrey.zhizhikin@leica-geosystems.com> wrote:

> Yes, but this was not picked up... At least, I do not see it applied on the master.
>
> From the entire series [1], the patch that shall solve the issue is [2], and it is
> the one I do not see applied onto master.

Correct. Hopefully, Stefano can apply it for 2023.01.

Regards,

Fabio Estevam