Should auth_cntr provide a return value?

[HH_Mov]

Using an i.mx93 in OEM_Open mode, I was validating the detection of invalidly signed containers.

The code in u-boot for "\include\configs\imx93_evk.h" implies that the auth_cntr returns a value which could be used in an "if statement" in the environment.

"auth_os=auth_cntr ${cntr_addr}\0" \
"mmcboot=echo Booting from mmc ...; " \
		"run mmcargs; " \
		"if test ${sec_boot} = yes; then " \
			"if run auth_os; then " \
				"run boot_os; " \
			"else " \
				"echo ERR: failed to authenticate; " \
			"fi; " \
		....

The check "if run auth_os; then" gives the impression that the success of the container validation is available as a return value. 

However testing shows that the result is always "0", for both a valid and invalid signed container. The ahab_status command does report errors after validating the invalid signed container.

Is this expected behavior for an OEM_Open device ? Or is the imx93_evk.h file implying something that is not there ?

[HH_Mov · Accepted solution]

It seems the result value only reports something about the execution of the auth_cntr command and not if the container itself is authentic.

For OEM_Open scenarios this might result in the "run boot_os" to be executed even when the container is not authentic.

For OEM_Closed scenarios, the call to auth_cntr will result in an immediate reboot, so the if statement will never be completed.

[Harvey021]

The auth_os verifies the container which is built with kernel and DTB. The ahab_status just reports what was verified.

Which version of BSP are you testing and what AHAB events?

Best regards

Harvey

[HH_Mov]

I am running a yocto scarthgap based image on an i.MX93 based board, running a rather old 2022.04 u-boot (at the moment).

The idea was to have a number of ahab containers:
  - 1st container: ELE, DDR FW, SPL
  - 2nd container: ATF, OP-TEE, U-Boot
  - 3rd container: Kernel
  - 4th container: dtb
  - ....nth

All containers are verified via the chain of trust, starting with ROM verifying the 1st, SPL the 2nd, u-boot the 3rd, 4th and possibly additional containers.

To verify the 3rd and 4th container in u-boot, I use the auth_cntr command and it provides info via ahab_status on the result. However the idea was to add this to a bootcmd, allowing each container to be validated and stopping or moving to a recovery mode on failure.

So the question I have is, how can I use the auth_cntr in an automated/scripted implementation? Or is adding these steps/verifications in the code itself and calling a custom command to handle these checks more suitable/normal practice?

[Harvey021]

Hope that the section <10.9 Security reference design> of the guide may help for you. 

Regards

Harvey