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-boun...@lists.denx.de> On Behalf Of Gaurav Jain
Sent: Friday, July 15, 2022 4:01 PM
To: ZHIZHIKIN Andrey <andrey.zhizhi...@leica-geosystems.com>
Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael Walle
<mich...@walle.cc>; Tommaso Merciai <tommaso.merc...@amarulasolutions.com>;
Michael Trimarchi <mich...@amarulasolutions.com>; Marek Vasut <ma...@denx.de>;
Simon Glass <s...@chromium.org>; Patrick Delaunay
<patrick.delau...@foss.st.com>;
Stefan Roese <s...@denx.de>; Horia Geanta <horia.gea...@nxp.com>; Pankaj Gupta
<pankaj.gu...@nxp.com>; Varun Sethi <v.se...@nxp.com>; Ye Li <ye...@nxp.com>;
dl-
uboot-imx <uboot-...@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.zhizhi...@leica-geosystems.com>
Sent: Friday, July 15, 2022 7:04 PM
To: Gaurav Jain <gaurav.j...@nxp.com>
Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael
Walle <mich...@walle.cc>; Tommaso Merciai
<tommaso.merc...@amarulasolutions.com>; Michael Trimarchi
<mich...@amarulasolutions.com>; Marek Vasut <ma...@denx.de>; Simon
Glass <s...@chromium.org>; Patrick Delaunay
<patrick.delau...@foss.st.com>; Stefan Roese <s...@denx.de>; Horia Geanta
<horia.gea...@nxp.com>; Pankaj Gupta <pankaj.gu...@nxp.com>; Varun
Sethi <v.se...@nxp.com>; Ye Li <ye...@nxp.com>; dl-uboot-imx <uboot-
i...@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-boun...@lists.denx.de> On Behalf Of Gaurav Jain
Sent: Friday, July 15, 2022 2:56 PM
To: ZHIZHIKIN Andrey <andrey.zhizhi...@leica-geosystems.com>
Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael
Walle <mich...@walle.cc>; Tommaso Merciai
<tommaso.merc...@amarulasolutions.com>;
Michael Trimarchi <mich...@amarulasolutions.com>; Marek Vasut
<ma...@denx.de>; Simon Glass <s...@chromium.org>; Patrick Delaunay
<patrick.delau...@foss.st.com>; Stefan Roese <s...@denx.de>; Horia
Geanta <horia.gea...@nxp.com>; Pankaj Gupta <pankaj.gu...@nxp.com>;
Varun Sethi <v.se...@nxp.com>; Ye Li <ye...@nxp.com>; dl- uboot-imx
<uboot-...@nxp.com>
Subject: RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on
imx8m series with CAAM enabled
Hello Andrey
There is a patch in review related caam hash.
Please check if it fixes your problem.
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
work.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20220616101009.809953-
1-&a
mp;data=05%7C01%7Cgaurav.jain%40nxp.com%7C4e78116cfe2b4487fdc208
da6666
aa79%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637934888408
633266%7
CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
TiI6Ik1
haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Dwe%2FOgeLeH
mWD7tKcmmJbV
%2F0D5cOZvH3kpCx%2FO%2FvMRg%3D&reserved=0
gaurav.j...@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.zhizhi...@leica-geosystems.com>
Sent: Friday, July 15, 2022 6:11 PM
To: Gaurav Jain <gaurav.j...@nxp.com>
Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael
Walle <mich...@walle.cc>; Tommaso Merciai
<tommaso.merc...@amarulasolutions.com>; Michael Trimarchi
<mich...@amarulasolutions.com>; Marek Vasut <ma...@denx.de>;
Simon
Glass <s...@chromium.org>; Patrick Delaunay
<patrick.delau...@foss.st.com>; Stefan Roese <s...@denx.de>; Horia
Geanta <horia.gea...@nxp.com>; Pankaj Gupta
<pankaj.gu...@nxp.com>;
Varun Sethi <v.se...@nxp.com>; Ye Li <ye...@nxp.com>; dl-uboot-imx
<uboot- i...@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-feste...@denx.de/
Link: [3]:
https://lore.kernel.org/all/20220709082951.15123-5-shawn...@kernel.org/
