HAB event in a Closed i.MX chip

[#1]

Background:

There have been instances when HAB FAILURE events are seen when running hab_status in u-boot or parsing the HAB log in HAB persistent memory after loading a signed bootable image through Serial download mode in an open (non-secure)/closed (secure) chip. The HAB FAILURE event creates a dilemma of why a Closed (secure) chip boots even after the BootROM has generated HAB event related to authentication failure of the signed image. However that is not the case and is explained below.

Sample output of this issue:

=> hab_status

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99

--------- HAB Event 1 -----------------

event data:

        0xdb 0x00 0x08 0x42 0x33 0x22 0x0a 0x00

STS = HAB_FAILURE (0x33)

RSN = HAB_INV_ADDRESS (0x22)

CTX = HAB_CTX_AUTHENTICATE (0x0A)

ENG = HAB_ENG_ANY (0x00)

Problem:

For the issue to be present in a i.MX chip, following are the requisites:

1. i.MX chip in Open/Closed mode
2. Internal fuse Boot mode or DIR_BT_DIS = 1 selected
3. Recovery Boot medium enabled in Boot configuration

After POR, the chip boots up according to the Internal fuse boot configuration. For ease of understanding, let’s consider the Primary boot medium selected is SD/EMMC and Recovery boot medium as ECSPI. The chip tries to boot from SD/EMMC and fails. Then it tries to boot from the Recovery boot medium and finds the ECSPI boot device on the board (which does not contain a properly signed image). When HAB tries to authenticate this image, it leads to authentication failure and HAB FAILURE event occurs. The chip then falls back into Serial Download mode.

Thereafter, a properly signed boot image is loaded through SDP mode (using MFGtool/imx_usb_loader), the HAB in BootROM authenticates the image properly and boots the chip. When the HAB log is parsed to check for any HAB events, the HAB FAILURE events generated during the authentication attempt of Recovery boot medium, are displayed.

Solution:

As the behavior seen in the chip in this scenario is by design, there is a way to determine whether the HAB FAILURE events seen after running the hab_status command in u-boot or parsing the HAB log in HAB persistent memory, are related to signed boot image loaded in SDP mode or not.

Parsing the BootROM log:

The BootROM log in the chip records the boot flow in the chip and thus, it can be used to determine if the HAB FAILURE event was generated before or after entering the SDP mode.

For example:

BootROM log in MX6QP in OCRAM:

0x00010002 <- Internal fuse

0x000200F0 <- Open chip

0x00030000 <- DIR_BT_DIS 0

0x00040000 <- BT_FUSE_SEL_VALUE 0

0x00050001 <- Sec Image select

0x00060001 <- SD boot selected

0x00070000 <- DEVICE_INIT_CALL

0x00070033 <- DEVICE_INIT_FAIL

0x00061004 <- ECSPI boot selected

0x00080000 <- DEVICE_READ_DATA_CALL

0x00000000

0x000800F0 <- DEVICE_READ_DATA_PASS

0x00090000 <- Authentication Status

0x000A2233 <- HAB_FAILURE

0x000C0000 <- SDP Entry

Here the HAB FAILURE event was generated before the chip goes into SDP mode, so it can be deduced that the HAB FAILURE event seen in the HAB log was due to the HAB failure while authenticating the Recovery boot medium instead of the image loaded through the SDP mode.

P.S. - Please email me for any suggestions/changes to this document.

P.P.S. - This document is up to date as of 08-20-2018