Does HAB fall back to a correctly signed boot partition, if current boot partition is wrongly signed?

Technical Support
, , ,
1

Dear Toradex community,

HAB is enabled on my Verdin iMX8M Plus and is working fine. I have implemented an A/B strategy for updating u-boot using two eMMC partitions - as described in Drew Moseley’s excellent article Considerations for Updating the Bootloader Over-the-Air.

The situation is as follows:

  • I installed a correctly signed u-boot (signed with an SRK from HAB) in boot partition 1.
  • I installed a wrongly signed or unsigned u-boot in boot partition 2 via an OTA update.
  • Boot partition is the active boot partition.

If I power on the device, the device boots and starts the main application - as if the dodgy u-boot in partition 2 doesn’t exist. A deeper analysis shows the following.

  • HAB tries to boot from u-boot in partition 2. It finds out that the signature is wrong. Sometimes it issues HAB events, sometimes not.
  • HAB skips booting from partition 2 and tries u-boot from partition 1. As partition 1 has a correct signature, it finishes booting and starts the application.

As my two u-boot instances have different LOCALVERSIONs, I can tell them apart from the u-boot messages (starting with U-Boot SPL and U-Boot) in the serial console. There are no messages from the dodgy u-boot.

If I zero out the good boot partition 1, the boot process gets stuck before a single u-boot message is printed in the serial console. There is no alternate u-boot to which the boot process can fall back.

Is this automatic fallback from a wrongly signed u-boot to a correctly signed u-boot a supported HAB feature? Or, is this fallback a lucky accident?

Thanks,
Burkhard

1 Like
2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello,

The behavior you’re observing, where the system automatically falls back from a wrongly signed U-Boot to a correctly signed one, is indeed a feature of the hardware and boot process design, rather than a lucky accident. This mechanism is part of the High Assurance Boot (HAB) process implemented in NXP’s i.MX processors, which includes the iMX8M Plus used in your Verdin module.

HAB is designed to enhance the security of the boot process by verifying the digital signatures of the bootloader and other firmware components against a set of preloaded Secure Boot Keys. If the verification fails (e.g., due to a wrongly signed or unsigned U-Boot), HAB will attempt to find a valid bootloader in the alternative boot partition if available. This is consistent with the eMMC standard, which specifies the possibility of having multiple boot partitions (typically two) that can be used for recovery purposes or to facilitate updates.

The A/B partitioning scheme you’ve implemented for updating U-Boot leverages this feature by allowing the system to fall back to a previously known good configuration if an update fails or is found to be untrustworthy. This is a common practice in robust OTA update mechanisms, providing a safety net to recover from potential issues during the update process.

The fact that HAB sometimes issues events and sometimes does not could depend on the specific configuration and state of the HAB. HAB events are logged when the HAB detects anomalies during its verification process, but the exact behavior can vary based on factors such as the HAB mode (e.g., Open or Closed) and the configuration of the system’s security features.

In summary, the fallback behavior you’ve experienced is a supported feature, designed to enhance the system’s security and reliability by ensuring that only verified firmware is executed. This mechanism is particularly valuable in embedded systems where uninterrupted operation is critical, and it aligns with best practices for secure firmware updates.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Secure Boot on Torizon OS | Toradex Developer Center.

3

When I looked at this a while ago there was nothing documented for this feature that I could find. However I did find the following:
i.MX8M Plus eMMC boot partitions - NXP Community

Andy

1 Like
4

Thanks for your reply. Your link describes the same behaviour that I’m seeing. And having humans confirm my experimental results is a lot more convincing then from an AI assistant :wink:

By the way, the ultimate reference confirming the fallback to the alternate boot partition is Section “7.2.3 Alternative boot operation (device optional)” in the JEDEC Standard JESD8484-A43 (PDF download) - aka the eMMC specification.

This feature is definitely working on the iMX8M SoMs (Plus/Nano/Mini). It would be interesting to find out on which other SoMs it is working. So, feel free to point out more SoMs with “alternate boot operation” in the comments.

5

This feature didn’t work for the iMX8M Mini as far as I know, but I haven’t checked this for the most recent versions of the chip.
The secondary boot method for iMX8M Mini involved the use of the Secondary Image Table and having both images in the same eMMC boot partition.
We now use the Plus rather than the Mini so I’m no longer up to date on whether there have been any changes to the boot ROM of the Mini.
I have no experience with the Nano…
Andy

1 Like
6

It’s not HAB, who tries to boot, but boot ROM. Boot ROM, depending on boot switches / pin striping, decides what to boot next, NAND/SD/etc. Perhaps eMMC is not error prone, but NAND is and multiple bootable copies make sense if one of them is broken/unreadable/etc… If you enable HAB, NAND ECC failures will lead as well to HAB failure. So why not to make HAB just an extra thing to check, and if that check fails, then just behave the same as what happens in case of uncorrectable ECC failure, just go seeking for healthy boot image.

1 Like
7

The fallback mechanism is also enabled on my iMX8M Nano as the following command shows:

# mmc extcsd read /dev/mmcblk2 | grep -B1 -A2 alternat
Boot Information [BOOT_INFO: 0x07]
  Device supports alternative boot method
  Device supports dual data rate during boot
  Device supports high speed timing during boot

The line “Device supports alternative boot method” tells us that the fallback to the other boot partition works.

8

Hello @bstubert,

As @Edward mentioned, the behavior you’re seeing is indeed a result of the i.MX8M Plus ROM code handling boot partition fallbacks. This mechanism is not a specific feature of HAB itself but rather the boot ROM’s strategy to handle boot failures.