Authenticating and booting AHAB-signed kernel on i.MX93

[Mihajlo]

Hello NXP Community,

Unfortunately, I couldn't find in forums the exact info I need, so I created this post.

In a nutshell: 

I have AHAB-signed imx-boot and kernel for i.MX93.

u-boot boots, but kernel won't.

I haven't written anything in SRK fuses yet... so I expect at least to have a bootable signed kernel and AHAB events generated as a result of different key hashes in signed container and in (empty) SRK fuses. I left writing fuses as the penultimate step... the last one is closing the device.

Here are the problems/questions:

1. auth_cntr for OS (kernel) container times out... (at least I think so)
         

           u-boot=> load mmc 0:3 ${kernel_addr_r} kernel_ahab_signed.bin

            20331520 bytes read in 86 ms (225.5 MiB/s)

           u-boot=> auth_cntr ${kernel_addr_r}

             Authenticate OS container at 0x8ff00000 

             mu receive msg wait 1s

              What does this reply/message mean?

2. There's a warning in offline image verification (see the attached file  ahab_kernel_container_verification.txt), but I don't understand it and I can't tell if it causes error described in (1).

           Is this warning a sign that something is not correct?

3. What is the proper command for/way of booting AHAB signed kernel? 

     booti (the one I use right now) gives an error when provided with OS container location in 
     memory:

         u-boot=> booti ${kernel_addr_r}
                   Bad Linux ARM64 Image magic!
     
     I tried bootm, just for check:

     Wrong Image Type for bootm command
      ERROR -91: can't get kernel image!

Any suggestion or hint is more than welcome, as are any links to documents explaining proper AHAB boot which I apparently missed

Thanks a lot to everyone in advance,

Mihajlo

[Mihajlo]

Hi Aldo,

I double-checked the boot command/script and performed everything manually (empty lines added for readability). Please note:  os_cntr_signed_yubikey.bin is the AHAB-signed kernel container... which also has .dtb in it... so I'm not sure if providing another .dtb in RAM is necessary at all:

u-boot=> ls mmc 0:3 /Delem/Boot
<DIR> 4096 .
<DIR> 4096 ..
20331520 os_cntr_signed_yubikey.bin
20331520 os_cntr_signed_cst.bin
134863824 rootfs.7.img
40629 imx93-delem.7.dtb

u-boot=> load mmc 0:3 ${fdt_addr_r} Delem/Boot/imx93-delem.7.dtb
40629 bytes read in 1 ms (38.7 MiB/s)

u-boot=> load mmc 0:3 ${kernel_addr_r} Delem/Boot/os_cntr_signed_yubikey.bin
20331520 bytes read in 88 ms (220.3 MiB/s)

u-boot=> load ${bootdev_config} ${loadaddr} Delem/Boot/rootfs.7.img
134863824 bytes read in 565 ms (227.6 MiB/s)

u-boot=> booti ${kernel_addr_r} ${loadaddr} ${fdt_addr_r}
Bad Linux ARM64 Image magic!


Do you have any idea what might be wrong in this case?

I'm not sure if the container address in RAM should be given to booti, or the container address has to have kernel offset within the container added to it.

[Mihajlo]

Hello Aldo,

Thanks for the prompt reply.

I'm glad that the warning 2 is not something to worry about.

However, regarding the point 1, I was not clear enough... u-boot does not wait for container authentification, I just get the u-boot prompt immediately, but I've seen that there should be an answer before new prompt.

So, here's how it looks exactly:

u-boot=> load mmc 0:3 ${kernel_addr_r} Delem/Boot/os_cntr_signed_yubikey.bin
20331520 bytes read in 88 ms (220.3 MiB/s)
u-boot=> auth_cntr ${kernel_addr_r}
Authenticate OS container at 0x8ff00000
mu receive msg wait 1s
u-boot=>

Does this look ok to you? To me, it looks as if the answer, i.e. the result of the authentication, is missing.





However, regarding the poi

[AldoG]

Hello,

Please see below the responses to your questions below:
1> This message means that the MU received the message, you'll need to wait untill it finish the authentication.

2> The warning seems to be because there is no secondary image, which should be fine.

3> I noticed that you have input only the kernel image address, please try using the following:

u-boot=> booti ${kernel_addr_r} - ${fdt_addr}

Best regards/Saludos,
Aldo.

[Mihajlo]

I think I might have found the root cause for booti not booting kernel...

Our version of u-boot is based on 2024.04... with additional specific commits.

As far as I could see, AHAB support in booti is available since 2025.04 version of u-boot.

At the moment I'm dealing with switching to 2025.04 for our system, as a proof of concept.

[AldoG]

Hello,

Sorry I missed your message, nice catch, yes you're correct this was added on uboot 2025.04, please have a look to the following commit:
https://github.com/nxp-imx/uboot-imx/commit/5da4255f28cdb9c59b0d4380a38e0e2a962b4465

Best regards/Saludos,
Aldo.