BL2 waits forever when BL3 (FIP) fails to verify

Yocto
1

I’m using genio1200 and genio510 platforms with secure boot enabled.
I’m still working with yocto kirkstone v24.1.
The documentation Secure Boot — IoT Yocto documentation says that BL2 should print an error on cosole, when signature verification of FIP image will fail. But in reality BL2 just hangs.

To test such scenario I’ve prepared BL2 and BL3 (FIP image) signed with different keys SECURE_BOOT_ROT_KEY.

Two problems were found so far:
1.
In common/bl_common.c in function static int load_auth_image_recursive there is a code:

rc = auth_mod_verify_img(image_id,
				 (void *)image_data->image_base,
				 image_data->image_size);
	if (rc != 0) {
		/* Authentication error, zero memory and flush it right away. */
		zero_normalmem((void *)image_data->image_base,
			       image_data->image_size);
		flush_dcache_range(image_data->image_base,
				   image_data->image_size);
		return -EAUTH;
	}

and program get stuck in function zero_normalmem
Function zero_normalmem() shall be used only when MMU is enabled. I’m not sure if BL2 is using MMU, but when I changed zero_normalmem() to zeromem() then it was not stuck. As result load_auth_image_recursive function returned -80, and finally debug message was printed:

"BL2: Failed to load image id 3 (-80)

Second problem is that just after that debug print program is intentionally hanged by calling __attribute__((__noreturn__)) plat_error_handler()

Is this expected behavior?
We have implemented OTA for BL2 and BL3 and I found that when I flash BL3 signed with wrong SECURE_BOOT_ROT_KEY, then BL2 it doesn’t automatically reboots which require from the user to power-off/on the device 9 times to trigger BL3 rollback to previous version.

3

hi @Lukasz_Plewa ,

For the MMU operation, it is recommended to start another discussion thread in the forum focusing on, especially comparing memory management and operations under conditions where the MMU is enabled or disabled.

For the topic “when BL3 (FIP) fails to verify”, each product may customize the handling of the authentication failure according to its own security requirements on the open platform. The implementation provided by the open platform is for reference only; error reporting or shutdown mechanisms can be flexibly adjusted based on product needs to meet the commercial requirements, ensuring both appropriate security and user experience.

Thank you.

1 Like