topic Re: Should auth_cntr provide a return value? in i.MX Processors

Should auth_cntr provide a return value?

HH_Mov — Tue, 22 Jul 2025 09:49:07 GMT

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 ?

Re: Should auth_cntr provide a return value?

Harvey021 — Fri, 25 Jul 2025 02:54:21 GMT

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

Re: Should auth_cntr provide a return value?

HH_Mov — Fri, 25 Jul 2025 06:38:45 GMT

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?

Re: Should auth_cntr provide a return value?

Harvey021 — Tue, 29 Jul 2025 13:50:53 GMT

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

Regards

Harvey

Re: Should auth_cntr provide a return value?

HH_Mov — Mon, 01 Sep 2025 06:09:14 GMT

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.