[BootROM/HABv4] - Redundant boot support is not triggered when first image's code is tampered

2 Kudos

1. Background

The ROM supports the redundant boot for an expansion device. The primary or secondary image is selected, depending on the PERSIST_SECONDARY_BOOT setting.

Both images need to be on the same flash (boot source).

In the Security Reference Manual/Reference, Manual redundant boot or secondary boot are the same - meaning the ROM has the capability to select which image to select from the 2 images located on the same flash.

NOTE: This functionality should not be confused with Manufacture Boot Support (also a ROM feature) - which refers to the ROM capability to boot an image from 2 different flashes (internal primary boot vs SDMMC MFG boot) before entering USB download mode (SDP)

If the PERSIST_SECONDARY_BOOT is 0, the boot ROM uses address 0x0 for the primary image.
If the PERSIST_SECONDARY_BOOT is 1, the boot ROM reads the secondary image table from address 0x200 on the boot media and uses the address specified in the table.

Reserved (chipNum)

Reserved (driveType)

tag

firstSectorNumber

Reserved (sectorCount)

Table 1. Secondary image table format

Where:

The tag is used as an indication of the valid secondary image table. It must be 0x00112233
The firstSectorNumber is the first 512-byte sector number of the secondary image

For the secondary image support, the primary image must reserve the space for the secondary image table. Refer to figure 1 below for the layout of the typical structure on an expansion device.

Figure 1. Expansion device structures layout

For the Closed mode (Security Configuration Enabled), if there are failures during primary image authentication, the boot ROM turns on the PERSIST_SECONDARY_BOOT bit and performs the software reset.

After the software reset, the secondary image is used. Details in Figure 2 below.

Figure 2. Boot flow (click on the image for zoom)

2. Issue description

The redundant boot is used only in correlation with HAB and secure boot. As you can see in Figure 2, the switch between the images is done only if the authentication fails.

The issue is that the redundant boot support is not triggered when the first image's u-boot code is tampered (not the header). This is because the reset operation after the failed authentication is not properly executed. The reset used by boot ROM to switch between the images is a warm reset - this warm reset is not correctly resetting the DDR controller that will impact the final DDR initialization when the DCD will be run for the second time by the secondary image. This is not reproduced when the header is altered, because the DCD is not run and the DDR initialization is not finished. So after the warm reset, the DDR initialization will successfully initialize.

2.1. Conditions to Reproduce

Secure boot enabled (Chip is closed- Security Configuration Enabled)
The real u-boot code of the first image is modified (not the header - IVT, DCD ..etc)

2.2. Execution flow to Reproduce

Prepare the images
1. Compile u-boot with HAB_SUPPORT
2. Sign both images using CST
3. Generate the necessary header for redundant boot using the information from here or just create one link the following.
4. Use the attached write_redundant.sh to write images on the SD card and if needed uncomment the last part to tamper the first image's code/u-boot
Flash the images on the SD/eMMC using the attached patches. Make sure you signed the images and closed the chip (aka secure boot is enabled successfully).
Modify the first image (only the u-boot code, not the header)
Boot the board
The primary image is downloaded
1. The DCD is executed and DDR initialization is done successfully
2. Authentication for the first image fails (because the u-boot was altered)
3. The persistent bit is set by boot ROM
4. A warm reset is triggered in order to switch to the secondary image (the warm reset is not correctly resetting/configuring the DDR controller to prepare it for another initialization)
The second image is downloaded (because the persistent bit was set)
1. The DCD is executed for the 2nd time and DDR initialization just fails hanging in the SoC/boot ROM

3. Impacted devices

All i.MX 6 (All devices and tape-outs)
All i.MX 7D/S (All devices and tape-outs)

Not Impacted

i.MX 7ULP
i.MX 8M, 8Mini, 8Nano - Not impacted as does not use DCD
i.MX 8 / 8x devices - Not impacted

4. Workarounds

Users should apply the attached patches based on the SoC type directly to u-boot.
The patches can be applied to both the first(primary) image and the secondary image, so no need to differentiate.

4.1. i.MX 6

Need to clear the bit17 of CCDR, otherwise, the system will hang up when ROM runs the DCD of the secondary image.

The reason is due to the ROM programming the wdg_warm_reset when the authentication of the first image failed, but it will also put the DDR into SR mode-the SDCLK to MMDC is off.
So, when ROM runs the DCD of the second image, the system will hang up.

In order to address the issue, we simply clear the bit17 of CCDR in DCD and restore it after u-boot boot up.

Please apply to u-boot the attached patch 0001-imx6sll-redundant-boot-fix.patch.

4.2. i.MX 7D/S

The DDR controller on the i.MX7D is different than i.MX6 (NXP MMDC controller). So the fix is different, needing to reset some DDR registers in order to make the DDR work when ROM runs the DCD to do the DDR initialization for the 2nd image.

Please apply to u-boot the attached patch 0001-imx7d-redundant-boot-fix.patch.

5. Conclusion

Adopting the suggested patches in the u-boot will fix the issue identified in this document.

This issue does not impact the Secure Boot flow and does not compromise the i.MX security.