[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
@ 2022-07-15 12:40 ZHIZHIKIN Andrey
  2022-07-15 12:56 ` [EXT] " Gaurav Jain
  2022-10-10 14:07 ` Rasmus Villemoes
  0 siblings, 2 replies; 17+ messages in thread
From: ZHIZHIKIN Andrey @ 2022-07-15 12:40 UTC (permalink / raw)
  To: gaurav.jain
  Cc: u-boot, festevam, sbabic, Michael Walle, Tommaso Merciai,
	Michael Trimarchi, Marek Vasut, Simon Glass, Patrick Delaunay,
	Stefan Roese, Horia Geanta, Pankaj Gupta, Varun Sethi, Ye Li,
	dl-uboot-imx

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

^ permalink raw reply	[flat|nested] 17+ messages in thread