u-boot crashed at caam_hash() while verifying sha256 checksum of fitimage

[benguan]

I am using the u-boot-fslc 2023.04 (https://github.com/Freescale/u-boot-fslc/tree/2023.04+fslc) for our OEM board with i.mx6ul. It works fine with HAB enabled on SPL and u-boot-ivt.img. I extended the HAB to fitImage with following patch on arch/arm/mach-imx/hab.c:

#ifdef CONFIG_IMX_HAB
	extern int authenticate_image(
			uint32_t ddr_start, uint32_t raw_image_size);

	switch (genimg_get_format((const void *)image_load_addr)) {
#if defined(CONFIG_LEGACY_IMAGE_FORMAT)
	case IMAGE_FORMAT_LEGACY:
		if (authenticate_image(image_load_addr,
			image_get_image_size((struct legacy_img_hdr *)image_load_addr)) != 0) {
			printf("Authenticate uImage Fail, Please check\n");
			return 1;
		}
		break;
#endif
#if defined(CONFIG_FIT)
	case IMAGE_FORMAT_FIT:
		if (authenticate_image(image_load_addr,
			fit_get_size((const void *)image_load_addr)) != 0) {
			printf("Authenticate fitImage Fail, Please check\n");
			return 1;
		}
		break;
#endif
#ifdef CONFIG_ANDROID_BOOT_IMAGE
	case IMAGE_FORMAT_ANDROID:
		/* Do this authentication in boota command */
		break;
#endif
	default:
		printf("Not valid image format for Authentication, Please check\n");
		return 1;
	}
#endif

And the fitImage passed the HAB verification but u-boot randomly crashed while verifying the sha256 of the Linux kernel:

Authenticate image from DDR location 0x82000000...

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found!

## Loading kernel from FIT Image at 82000000 ...
   Using 'conf-map55-com.dtb' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x82000104
     Data Size:    4008418 Bytes = 3.8 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x80008000
     Entry Point:  0x80008000
     Hash algo:    sha256
     Hash value:   744b87b907338047510bf0e8682d1faf49d224712e32bf0a9890bf0a938a03af
   Verifying Hash Integrity ... sha256@1: 0x82000104, 4008418, 0x9ef56c00
@2: 0x9ef6de40, 4008448
CACHE: Misaligned operation at range [82000104, 823d2b04]
@3
@4: 256
@5: 64
@6
@jr2

The same logic worked well with our another i.mx6ul OEM board but with u-boot-fslc 2020.10. The crash came from jr_enqueue() (drivers/crypto/fsl/jr.c). I checked jr.c between u-boot-fslc 2020.10 and u-boot-fslc 2023.04 and found the difference is: u-boot-fslc 2020.10 uses a hardcoded jr.c in source while u-boot-fslc 2023.04 switches to device tree.

Does anyone have the similar issue or any hint to tackle it?

Thanks in advance.

Updated on 2023/09/21, after digging into it a little more, the fitimage sha256 checksum is moved from software algorithm to software or hardware depending on the configuration in u-boot 2022.01 (https://github.com/Freescale/u-boot-fslc/commit/92055e138f2873034e2dfd7e1308e30c9bbef3b1). The hw acceleration version caam_hash() in fsl_hash.c will be crash once hab_rvt_authenticate_image() is called on a fitImage no matter if HAB is enabled or not.  Calling `hab_auth_img` command on a fitImage in u-boot prompt and then use a hash command will always crash.

[benguan]

@hector_delgado Thanks. Looking for your result. I currently reverted commit https://github.com/Freescale/u-boot-fslc/commit/92055e138f2873034e2dfd7e1308e30c9bbef3b1 to switch back to software hash implementation as a temporary workaround and it works.

[hector_delgado]

Hi @benguan ,

I hope you're doing well. The GitHub repository isn't from our official BSP, so we unfortunately don't support it. We also don't support FIT on the i.MX 6UL. 

I'd recommend porting this uboot-imx/drivers/crypto/fsl/fsl_hash.c at lf_v2022.04 · nxp-imx/uboot-imx · GitHub which showcases HW hashing. 

Let me know if this was of any help!

Best regards,
Hector.

[hector_delgado]

Hi @benguan ,

I hope you're doing well! Let me review this issue and double check if we encountered this issue previously. I'll get back to you as soon as possible. Thank you.

Best regards,
Hector.

[mprt42]

Hi @hector_delgado ,

any news on this?
I'm stumbling over the same issue.

For now, disabling caam support and using the software implementation of sha256 seems to do the trick, but it's of course no proper solution...
Thanks!

[benguan]

@mprt42 The working solution I got from NXP is : add 'status ="disabled"' to sec_jr0 in imx6ul.dtsi.