caam_hash() crashes after authenticating a signed fitImage with hab_auth_img

[freebendy]

Hello, with the 2023.04 u-boot-fslc on a imx6ul board, I built images signed with CST. HAB works good with SPL and u-boot-ivt.img. While I tried to authenticate a signed fitImage, the authentication did pass, but calculating sha256 after the hab_auth_img crashes as follow ( "@@" message are added by me). The same feature works well with in previous 2020.10+fslc branch.

[2023-04-28 08:50:47.282] •Ó-Boot SPL 2023.04+yocto (Apr 27 2023 - 21:54:08 +0000)
[2023-04-28 08:50:47.304] MAP55 BOOT_DEVICE_NAND
[2023-04-28 08:50:47.304] Trying to boot from NAND
[2023-04-28 08:50:47.507] hab fuse not enabled
[2023-04-28 08:50:47.507]
[2023-04-28 08:50:47.507] Authenticate image from DDR location 0x877fffc0...
[2023-04-28 08:50:47.747]
[2023-04-28 08:50:47.747]
[2023-04-28 08:50:47.747] U-Boot 2023.04+yocto (Apr 27 2023 - 21:54:08 +0000)
[2023-04-28 08:50:47.747]
[2023-04-28 08:50:47.747] CPU: Freescale i.MX6UL rev1.2 528 MHz (running at 396 MHz)
[2023-04-28 08:50:47.747] CPU: Industrial temperature grade (-40C to 105C) at 41C
[2023-04-28 08:50:47.771] Reset cause: POR
[2023-04-28 08:50:47.771] Board: unknown (version=0x0)
[2023-04-28 08:50:47.772] DRAM: 512 MiB
[2023-04-28 08:50:47.823] Core: 35 devices, 16 uclasses, devicetree: separate
[2023-04-28 08:50:47.823] WDT: Started watchdog with servicing every 125ms (128s timeout)
[2023-04-28 08:50:47.840] NAND: 512 MiB
[2023-04-28 08:50:47.840] MMC:
[2023-04-28 08:50:47.840] Loading Environment from NAND... OK
[2023-04-28 08:50:47.857] In: serial
[2023-04-28 08:50:47.857] Out: serial
[2023-04-28 08:50:47.857] Err: serial
[2023-04-28 08:50:47.920] SEC0: RNG instantiated
[2023-04-28 08:50:47.920] Unsupported board variant!
[2023-04-28 08:50:47.920] Net: eth0: ethernet@2188000
[2023-04-28 08:50:47.965] Saving Environment to NAND... Erasing NAND...
[2023-04-28 08:50:47.966] Erasing at 0x400000 -- 100% complete.
[2023-04-28 08:50:47.966] Writing to NAND... OK
[2023-04-28 08:50:47.966] OK
[2023-04-28 08:50:47.966] Normal Boot
[2023-04-28 08:50:47.966] Warning: Bootlimit (2) exceeded. Using altbootcmd.
[2023-04-28 08:50:47.966] Hit any key to stop autoboot: 3 0
[2023-04-28 08:50:47.966] => mtdparts default; run nandargs; run setkernelcmd; ubi part ubi; ubi read ${loadaddr} kernel${kernel2boot}; mtdparts default; run nandargs; run setkernelcmd; ubi part ubi; ubi read ${loadaddr} kernel${kernel2boot};
[2023-04-28 08:52:39.073] ubi0: attaching mtd4
[2023-04-28 08:52:43.132] ubi0: scanning is finished
[2023-04-28 08:52:43.218] ubi0: attached mtd4 (name "ubi", size 507 MiB)
[2023-04-28 08:52:43.218] ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes
[2023-04-28 08:52:43.218] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
[2023-04-28 08:52:43.218] ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
[2023-04-28 08:52:43.218] ubi0: good PEBs: 2024, bad PEBs: 4, corrupted PEBs: 0
[2023-04-28 08:52:43.218] ubi0: user volume: 7, internal volumes: 1, max. volumes count: 128
[2023-04-28 08:52:43.218] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 319844601
[2023-04-28 08:52:43.218] ubi0: available PEBs: 410, total reserved PEBs: 1614, PEBs reserved for bad PEB handling: 36
[2023-04-28 08:52:43.218] No size specified -> Using max size (10665984)
[2023-04-28 08:52:43.218] Read 10665984 bytes from volume kernel2 to 82000000
[2023-04-28 08:52:44.463] => hash 256 sha256 0x7 802 2000000 100
[2023-04-28 08:52:58.013] @@ 1
[2023-04-28 08:52:58.013] @@ 2 size: 256
[2023-04-28 08:52:58.013] @@ 3
[2023-04-28 08:52:58.040] @@ 4 size: 256
[2023-04-28 08:52:58.040] @@ 5 size: 64
[2023-04-28 08:52:58.040] @@ 6 ret: 0
[2023-04-28 08:52:58.040] @@ 7 size: 64
[2023-04-28 08:52:58.040] sha256 for 82000000 ... 820000ff ==> c309f8a33edc8bdb75c6a7d17d330d2eabcaa17ec34d60ef03f9759b8eec2b34
[2023-04-28 08:52:58.040] => hab_auth_img 0x82000000 0x499f60 0x499000
[2023-04-28 08:53:09.111] hab fuse not enabled
[2023-04-28 08:53:09.132]
[2023-04-28 08:53:09.132] Authenticate image from DDR location 0x82000000...
[2023-04-28 08:53:09.179]
[2023-04-28 08:53:09.179] Secure boot disabled
[2023-04-28 08:53:09.179]
[2023-04-28 08:53:09.179] HAB Configuration: 0xf0, HAB State: 0x66
[2023-04-28 08:53:09.179] No HAB Events Found!
[2023-04-28 08:53:09.179]
[2023-04-28 08:53:09.179] => hab_auth_img 0x82000000 0x499f60 0x499000 hash sha256 0x82000000 100
[2023-04-28 08:53:13.583] @@ 1
[2023-04-28 08:53:13.583] @@ 2 size: 256
[2023-04-28 08:53:13.583] @@ 3
[2023-04-28 08:53:13.583] @@ 4 size: 256
[2023-04-28 08:53:13.583] @@ 5 size: 64
[2023-04-28 08:53:13.583] @@ 6 ret: 269297864
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort
[2023-04-28 08:53:13.583] data abort

[freebendy]

After some debugging, the issue might be introduced by commit 1d756ad. If the hab is disabled and there is no SRKs programmed in the efuse (I think it is the normal case during development), calling hab_rvt_authenticate_image() in imx_hab_authenticate_image() leads to this randomly failure. After I added the following code if (!imx_hab_is_enabled()) goto hab_authentication_exit; before the hab_rvt_authenticate_image() to avoid the call. It succeeded to boot into Linux user space.

[fabioestevam]

@freebendy

Please submit your fix via the U-Boot mailing list, with all the folks involved in commit
1d756ad on Cc.

Thanks

[otavio]

@freebendy I merged your PR. Thanks for looking at it. Please prepare a PR to fix this error as well.

[freebendy]

@otavio Thanks. I need a guidance here. The mainline u-boot does not support kernel HAB in bootm command yet, and the imx u-boot adds support of the legacy uImage in nxp-imx/uboot-imx@3b09ef6. I added the support of fitImage HAB on top of the imx commit above. I have 2 change commits on hand:

• support fitImage HAB
• fix the crash issue
  But I am not sure which u-boot (mainline, imx or fslc) should I create the PRs to.

[fabioestevam]

@freebendy

I suggest submitting the patches to the U-Boot mainline list first. After it gets reviewed there, then send a PR against u-boot-fslc.

Thanks