Secure boot issue with HAB_INV_ADDRESS for i.MX6DL custom board

[shunnianzhai]

Hi All,

We have an i.MX6DL custom board with the following information:

   CPU:   Freescale i.MX6DL rev1.2 at 792 MHz

   U-Boot 2017.11-imx6dl

Now we want to add the secure boot feature for this board.

I follow the instructions in the doc "AN4581.pdf" (Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using HABv4) to generate the signed u-boot image.

However, when I reprogram the signed u-boot.imx image to the flash and reboot the device to check the HAB status, it shows the following events:

=> hab_status
Secure boot disabled
HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x08 0x41 0x33 0x22 0x0a 0x00

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ADDRESS (0x22)
CTX = HAB_CTX_AUTHENTICATE (0x0A)
ENG = HAB_ENG_ANY (0x00)

--------- HAB Event 2 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x17 0x7f 0xf4 0x00
0x00 0x00 0x00 0x20

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)

--------- HAB Event 3 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x17 0x7f 0xf4 0x2c
0x00 0x00 0x02 0x38

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)

--------- HAB Event 4 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x17 0x7f 0xf4 0x20
0x00 0x00 0x00 0x01

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)

--------- HAB Event 5 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x17 0x80 0x00 0x00
0x00 0x00 0x00 0x04

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)

During the testing, I notice that the same messages above are showed for both signed and unsigned u-boot.imx images.

Could anyone help advise what could be the root cause? Any suggestion to resolve the issue?

Here are more info for your reference:

1) i.MX 6 DualLite Silicon rev: 1.2 (not latest rev)

Below is Silicon rev vs HAB version abstracted from doc "AN4581.pdf":

------------------------------------------------------------------
Chip                      Silicon revision    HAB version
i.MX 6 DualLite     TO 1.2                   HAB 4.1.1
                             TO 1.4                    HAB 4.2.7

2) The IVT table from u-boot binary as below:

od -X -N 0x20 u-boot.imx
0000000 402000d1 17800000 00000000 177ff42c
0000020 177ff420 177ff400 1785f000 00000000
0000040

Thanks in advance for your any suggestions.

Best Regards,

Shunnian

[Yuri]

shunnianzhai 

Hello,

  I've sent You some comments.

Regards,

Yuri.

[shunnianzhai]

Hi Yuri,

Thank you for sending me so many files. I will take a look to see if I can find any useful info.

However, it seems that most of them are old posts in 2013-2015.

Some steps and instructions may be different or unnecessary for latest u-boot and cst tool.

For example, pad the u-boot image by the following command:

$ objcopy -I binary -O binary --pad-to 0x5AC00 --gap-fill=0xff u-boot.imx u-boot-pad.bin

It seems that this is already done when building the u-boot image with latest u-boot code.

The doc "AN4581.pdf" which I referred to is Rev. 2, 05/2018, which includes the latest instructions from NXP.

FYI:

We have another i.MX 6 Quad custom board with Silicon rev 1.6 and HAB version 4.2.7. 

Previously, I followed the same procedures in this doc to sign the u-boot for this i.MX6Q board. Everything works properly.

I notice that HAB version is different in these two custom boards (HAB 4.1.1 vs 4.2.7).

So, I change the version in CSF from original 4.2 (for i.MX6Q board) to either 4.1 or 4 as below but neither works

---------------------------------------------------------------------------------

#Illustrative Command Sequence File Description [Header]
Version = 4     (or 4.1)
Hash Algorithm = sha256
Engine = ANY
Certificate Format = X509
Signature Format = CMS

Do you know if other changes are required due to the different HAB version?

Do you have any other suggestion?

Thanks,

Shunnian

[liu_kui]

Hi, Shunnian 

Looks like i had similar issues as yours. And I managed to found the root cause. 

Can you dump the Boot Data from your u-boot.imx and check whether the length includes the CSF section.  The correct length value should be  "sizeof(u-boot.imx) + 0x400(image offset in eMMC/SD) + 0x2000(CSF size)" .  

[shunnianzhai]

Hi Liu Kui,

Thanks for your information and sharing your experience and solution to the issue.

Could you share with me on how to dump the boot data from u-boot.imx to check the length?

Below are more data for your reference:

1) Followed is the IVT table from my u-boot.imx and also how I calculate the image length used for CSF description file:

od -X -N 0x20 u-boot.imx
0000000 402000d1 17800000 00000000 177ff42c
0000020 177ff420 177ff400 1785f000 00000000
0000040

-------------------------------------------------------------
Table: IVT table layout
-------------------------------------------------------------
Offset Name Value
-------------------------------------------------------------
0 IVT Header 402000d1
4 U-Boot entry point 17800000
8 Reserved 1 00000000
12 DCD PTR 177ff42c
16 Boot Data PTR 177ff420
20 IVT Self 177ff400
24 CSF PTR 1785f000
28 Reserved 2 00000000
-------------------------------------------------------------

IVT address: 0x177ff400
Image length: CSF PTR – IVT Self = 0x1785f000 – 0x177ff400 = 0x5FC00

In CSF [Authenticate Data] field:
Blocks = 0x177ff400 0x00000000 0x0005FC00 "../u-boot_dir_ap/u-boot.imx"

2) Followed is more data dumped from u-boot.imx. Could you locate the boot data length from here?

od -X -N 0x60 u-boot.imx
0000000 402000d1 17800000 00000000 177ff42c
0000020 177ff420 177ff400 1785f000 00000000
0000040 177ff000 0006000c 00000000 403802d2
0000060 043402cc 74070e02 00000c00 54070e02
0000100 00000000 ac040e02 30000000 b0040e02
0000120 30000000 64040e02 30000000 90040e02
0000140

3) followed is information by running mkimage tool:

/u-boot-fslc/1.0-r0/build$ tools/mkimage -l u-boot.imx
Image Type: Freescale IMX Boot Image
Image Ver: 2 (i.MX53/6/7 compatible)
Mode: DCD
Data Size: 393228 Bytes = 384.01 KiB = 0.38 MiB
Load Address: 177ff420
Entry Point: 17800000

Q: what is the data size (393228 Bytes)? 

I notice that this is different with the the file size below, which is 392192 bytes for u-boot.imx.

4) Followed is to list the file size for all relative files:

/cst/release/u-boot_dir_ap$ ll
total 21084
drwxrwxr-x 2 snzhai snzhai 4096 Jul 28 15:35 ./
drwxrwxr-x 13 snzhai snzhai 4096 Jul 20 16:58 ../
-rw-rw-r-- 1 snzhai snzhai 1067 Jul 28 15:35 csf-uboot
-rw-rw-r-- 1 snzhai snzhai 3896 Jul 28 15:35 csf-uboot.bin
-rw-r--r-- 1 snzhai snzhai 392192 Jul 24 19:11 u-boot.imx
-rw-rw-r-- 1 snzhai snzhai 396088 Jul 28 15:35 u-boot-signed.imx

Thanks in advance for your help.

Please let me know if you need more info.

Thanks and regards,

Shunnian

[liu_kui · Accepted solution]

The IVT Self PTR is 177ff400, which is the beginning of u-boot.imx, the Boot Data PTR is 177ff420, which is offset 0x20 of the u-boot.imx. So the third line of your od dump is the Boot Data:

0000040 177ff000 0006000c 00000000 403802d2. 

As your can see the length in your boot data  is 0x6000c,  which means boot rom will only copy 0x60200 bytes( eMMC block size is 512) of data from the beginning of eMMC to DRAM. Since the u-boot.imx needs to be put at offset 0x400 in eMMC, and the size of your u-boot.imx is already 0x5FC00(without CSF),  then  only the first 0x200 bytes of CSF will be loaded to DRAM, which clearly is wrong.  

I think this should be a bug in the FSL offfical u-boot, the best solution should be modify u-boot source code to generate a correct value , however I haven't figured out how to do that.  Instead you can also manually change the length value to your u-boot.imx,  the correct length value should be 0x62000 (0x400 + 0x5FC00 +0x2000(assume your CSF size is 0x2000, though padding CSF is optional))  in your case. Hope this will solve your problem. 

[shunnianzhai]

Hi Liu Kui,

Update on my test result:

Per your suggestion, I manually modify the boot data length to the correct value 0x62000. Now the hab_status command shows no event as below:

=> hab_status

Secure boot disabled

HAB Configuration: 0xf0, HAB State: 0x66
No HAB Events Found!

To do next, needs to figure out where the u-boot code causes this incorrect length issue.  If you have any idea, please share with me.

Currently, I encountered another big issue since my device is locked after I close it. 

Since the u-boot can boot correctly without any HAB events, I was going to close the device to further verify my signed images for kernel. After following the instructions to close the device, it cannot reboot anymore.

I notice the following information:

After the device successfully boots a signed image without generating any HAB events, it is safe to
secure, or close, the device. This is the last step in the process, and is completed by blowing the
SEC_CONFIG[1] fuse bit. Once the fuse is blown, the chip does not load in image that has not been signed
using the correct PKI tree.

Do you know if there is any way to recover and make the device boot again?

Thanks and regards,

Shunnian

[liu_kui]

Hi, Shunninan

I'm quite shocked by your result as I haven't tried to close my device because i have another HAB warning event to fix.  Sorry I have no idea right now how to recover a locked device.  As for the u-boot, I'll share with you once i find out a fix.

Your result reminds me of the issue reported in,i.MX6 HAB secure boot fuse problem .  It seems sometimes using a 4096-bit key can cause  the device fail to boot after close even HAB reports no events before.  Hope your issue is same as what's reported in that link.

Regards,

Liu Kui

[shunnianzhai]

Hi Liu Kui,

Thanks for your information.

My case may be different with one in the link you provided.

I am using the 2048-bit certificate, not 4096-bit, with the following settings in CSF file:

Hash Algorithm = sha256
Engine = ANY

Not sure what I should do next to resolve the issue. Welcome on any suggestion.

Thanks and regards,

Shunnian

[liu_kui]

Hi, Shunnian 

It looks like a different issue,  sorry i can't offer any help here. I think you need NXP's support. 

Back to the HAB_INV_ADDRESS issue, I finally found out the culprit in u-boot source code, which is the following line in the 'board/<your board>/imximage.cfg" file

#ifdef CONFIG_SECURE_BOOT

CSF    CONFIG_CSF_SIZE

#endif

The problem is somehow the compiler fails to expand the macro CONFIG_CSF_SIZE to its hex value when generating corresponding imximage.cfgtmp.  So the fix is to replace CONFIG_CSF_SIZE to actual hex value directly , for example

#ifdef CONFIG_SECURE_BOOT

CSF    0x4000

endif

Regards,

Liu Kui 

[shunnianzhai]

Hi Liu Kui,

Great! Thanks for your good findings.

Yes, for my case, per your suggestion, I modify the CSF to 0x4000 and rebuilt the u-boot. It generates the correct boot data length this time.

One Q on CSF size, 0x4000 or 0x2000, which value is correct?

As for the "locked" issue after programming to "close" the device, yes, I will continue to ask NXP for support.

BTW, have you tried out to go to the steps to "close" your device?

Thanks and best regards,

Shunnian

[liu_kui]

Hi, Shunnian

I think both 0x4000 and 0x2000 should be OK in your case. Bottom line is it must be larger than the actual CSF size generated by cst. 

I'm still trying to fix the warning problem which fortunately is a known problem in latest bootrom. I'll try to close my device once the warning problem is fixed.  

Regards,

Liu Kui

[shunnianzhai]

Hi Liu Kui,

Thanks for your information.

Hope that you can resolve your current issue soon.

FYI:

The root cause for my issue that the device cannot boot may be identified.

Refer to the link below for detail:

https://community.nxp.com/thread/539664 

Which part are you using in i.MX6 family? Pls check the HAB version for your part to avoid the similar problem I had.

Thanks and regards,

Shunnian

[shunnianzhai]

Hi Liu Kui,

Thanks for your pointing out the possible root cause.

I will try to manually modify the boot data length to test if it works first.

Will update you on the test result once it is done.

Thanks and regards,

Shunnian