i.MX6UL with Secure Boot and HAB errors

[kinezo]

I can't seem to find definitive information on what the cause may be to the HAB Event error of (0x22) or HAB_INV_ADDRESS.

--------- 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)

Can anyone help point me to the proper documentation?

I've gone through AN4581.pdf and HAB4_API.pdf and HABCST_UG.pdf.

Here's some further info about my setup.

Here's my CSF:

[Header]
Version = 4.2
Hash Algorithm = sha256
Engine = SW
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS

[Install SRK]
File = "../crts/SRK_1_2_3_4_table.bin"
Source index = 0 # Index of the key location in the SRK table to be installed

[Install CSFK]
# Key used to authenticate the CSF data
File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate CSF]

[Unlock]
Engine = CAAM
Features = RNG

[Install Key]
# Key slot index used to authenticate the key to be installed
Verification index = 0
# Target key slot in HAB key store where key will be installed
Target Index = 2
# Key to install
File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate Data]
# Key slot index used to authenticate the image data
Verification index = 2
# Address Offset Length Data File Path
Blocks = 0x877ff400 0x0 0x074000 "./u-boot-padded.imx"

my u-boot.imx is 0x73c00 in size padded to 0x74000 using the documented objcopy command:

objcopy -I binary -O binary --pad-to 0x74000 --gap-fill=0x5A u-boot.imx u-boot-padded.imx

IVT looks like:

> xxd -g 4 -l 48 u-boot-signed.imx
0000000: d1002040 00008087 00000000 2cf47f87 .. @........,...
0000010: 20f47f87 00f47f87 00308787 00000000 ........0......
0000020: 00f07f87 00600700 00000000 d201e040 .....`.........@

Any help/pointers/tips to get me going in the right direction would be greatly appreciated. Thanks!

[kinezo · Accepted solution]

Actually, now that I look back at the thread, I think I know why it didn't work. :smileyhappy:

Whatever instructions I read, had them padding the u-boot.imx. That doesn't make sense because the CSF goes at the end of it and the start address of the CSF is IN the IVT. If you pad u-boot, that'll push the CSF beyond where the IVT says it is!!

This time around, I didn't pad the u-boot blob. I'm not 100% certain, but i'm fairly confident that's why it didn't work the first time around.

Thanks again!

[kinezo]

Hi Yuri, I just noticed something in the IVT header I posted above. You'll see it starts with the IVT header:

d1002040

and a little later, the DCD header:

d201e040

However, the addresses of the other parts of the IVT seem to be in the wrong ENDIANESS!? As stated above, the TEXT_BASE for the IMX6UL is 0x87800000, but the generated IVT addresses don't match the endianess of the IVT header and DCD header!

Does that seem like it would be the culprit causing the "HAB_INV_ADDRESS" error?

I'll experiment by manually changing those addresses in my u-boot.imx.

Obvious secondary question to that would be, why would u-boot be generating the IVT like that? I assume *I'm* configuring it incorrectly? If you have insight into that, that would help, in the meantime, I'm going to try to experiment with manually fixing those addresses.

[kinezo]

I might have jumped a bit too quick at endianess issue. Looking at others' IVTs, it does seem like it's correct afterall:

>dd if=./u-boot.imx bs=4 count=12 2>/dev/null | hexdump -v -e '/4 "%04_ax: "' -e '/4 "%08X" "\n"'
0000: 402000D1
0004: 87800000
0008: 00000000
000c: 877FF42C
0010: 877FF420
0014: 877FF400
0018: 87873000
001c: 00000000
0020: 877FF000
0024: 00076000
0028: 00000000
002c: 40E001D2

Back to the drawing board.

[kinezo]

Going back to the endianess issue :smileyhappy:

Here's a DDR memory dump of the IVT directly from u-boot:

=> md 0x877ff400
877ff400: 402000d1 87800000 00000000 877ff42c .. @........,...
877ff410: 877ff420 877ff400 87873000 00000000 ........0......
877ff420: 877ff000 00076000 00000000 40e001d2 .....`.........@
877ff430: 04dc01cc 68400c02 ffffffff 6c400c02 ......@h......@l
877ff440: ffffffff 70400c02 ffffffff 74400c02 ......@p......@t
877ff450: ffffffff 78400c02 ffffffff 7c400c02 ......@x......@|
877ff460: ffffffff 80400c02 ffffffff b4040e02 ......@.........

My understanding of how you'd read this makes me think the addresses in the IVT are not correct. You can see the beginning of the DCD too. Comparing with the above from the imximage.cfg:

DATA 4 0x020c4068 0xffffffff

So from the u-boot md command, that address shows up as: 68400c02 (2nd 32bits from line: 877ff430)

But the addresses in the IVT from line 877ff400 and 877ff410 don't seem correct to me? Wouldn't the HAB read that CSF address as: 87873000 -> 00308787 ? (CSF being the 3rd set of 32bits from line: 877ff410) which is definitely not a valid address.

[kinezo]

Just in case it may help:  I'm getting the same HAB errors even when I load up a u-boot WITHOUT the CSF. So it doesn't look like it's getting very far in its verification process. (i.e. Not even reaching the CSF yet)

[Yuri]

Hello,

  please try the following U-boot :

http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git -b imx_v2016.03_4.1.15_2.0.0_ga

Uncomment " #define CONFIG_SECURE_BOOT" in "uboot-imx/include/configs/mx6ul_14x14_evk.h"

to enable secure configure, build u-boot.

Regards,

Yuri.

[kinezo]

Hi Yuri, I just tried that repo. The u-boot built with the mx6ul_14x14_evk target does not run on the pico-hobbit-imx6ul board I'm working on.

I've tried the 2 different DCDs (if you look at the imximage.cfg in uboot-imx/board/freescale/mx6ul_14x14_evk you'll see an ifdef for a newer type of DDR ram they must be using). Even the older DDR definition is slightly different than the DCD from the technexion/pico-imx6ul/imximage.cfg. I tried that DCD as well. Still didn't boot.

I might try a different imx6ul board. I believe we have one of those 14x14_evk boards here. I'll try getting HAB to work on that board, and go from there.

[Yuri]

Hello,

  I am not sure if Your U-boot supports HAB (" #define CONFIG_SECURE_BOOT").

Perhaps it makes sense to apply to board supplier / manufacturer for proper U-boot,

supporting HAB.

Regards,

Yuri.

[kinezo]

Hey Yuri, thanks again for all your help. I took a break from it and recently tried it with the IMX6ULL EVK board I mentioned and it worked! I then tried it again with the IMX6UL board from this original question and it also now works!

Sometimes, you  just need to step away apparently?! :smileyhappy:

Thanks again for taking the time to respond to all my questions.

[kanimozhi_t]

Hey Joe,

    It's great to hear you got it working in IMX6ULL EVK board! Currently, I'm trying to achieve the same. Any insights or help would be much appreciated.

[kinezo]

Hey, it's been a while and honestly, I don't remember anything beyond my last post there with all the sample commands. Sorry I couldn't be more helpful.

Good luck!

[huzaifi]

Hey Joe,

I having some trouble with the i.MX6ULL HAB uboot. I was hoping you might be able to help since you are one of the few that got it going. 

Can you tell me in detail how you signed the Uboot and how you flashed it to your eMMC? Also, may I have a look at your CSF file. 

Thanks

[kinezo]

Here's my CSF:

[Header]
Version = 4.2
Hash Algorithm = sha256
Engine = Any
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS

[Install SRK]
File = "../crts/SRK_1_2_3_4_table.bin"
Source index = 0 # Index of the key location in the SRK table to be installed

[Install CSFK]
# Key used to authenticate the CSF data
File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate CSF]

[Install Key]
# Key slot index used to authenticate the key to be installed
Verification index = 0
# Target key slot in HAB key store where key will be installed
Target Index = 2
# Key to install
File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate Data]
# Key slot index used to authenticate the image data
Verification index = 2
# Address Offset Length Data File Path
Blocks = 0x877ff400 0x00000000 0x0008ac00 "./u-boot.imx"

Remember, you need to get the proper "Blocks" line for your own image. You can usually get it with a command like this from the root of your u-boot src tree:

tools/mkimage -n board/technexion/pico-imx6ul/imximage.cfg.cfgtmp -T imximage -e 0x87800000 -d ./boot.bin ./u-boot.imx

After that, we run this to generate the CSF blob:

../linux64/cst -o u-boot-csf.bin -i u-boot.csf

We then pad the CSF to 16KB (16KB = 0x4000 in hex):

objcopy -I binary -O binary --pad-to 0x4000 --gap-fill=0x00 u-boot-csf.bin u-boot-csf-padded.bin

Finally, we put the CSF and u-boot together:

cat u-boot.imx u-boot-csf-padded.bin > u-boot-csf-signed.imx

Remember, CSF gets appended to the end of u-boot. Also remember to confirm that your IVT is pointing to the right memory address of where the CSF starts.

Good luck!

[Yuri]

Hello,

  Do You use NXP BSP ? 

Regards,

Yuri.

[kinezo]

No, we're using the freescale bsp. (Is that the same now?)

For u-boot specifically, we're using the 2016-07 branch from u-boot-fslc:

GitHub - Freescale/u-boot-fslc at 2016.07+fslc 

[kinezo]

Hi YuriMuhin_ng‌, thanks for the response. And sorry, was away for a few days.

As per the IMX6UL Ref Manual in Table 8-31, It seems I'm in the DCD range:

Also, from the u-boot src (from the fslc-2016-07 branch) TEXT_BASE is 0x87800000:

All seems to check out. Any other thoughts on why a 0x22 (HAB_INV_ADDRESS) error would occur?

[Yuri]

Hello,

  please check DCD table in U-boot code :

board/freescale/mx6<customer_board_name>/imximage.cfg

Regards,

Yuri.

[kinezo]

Hi Yuri, I'm using the imximage.cfg from Technexion (as I'm currently testing out their pico-hobbit with an IMX6UL). DCD looks like it's in range as well:

#define __ASSEMBLY__
#include <config.h>

/* image version */

IMAGE_VERSION 2

/*
* Boot Device : one of
* spi/sd/nand/onenand, qspi/nor
*/
BOOT_FROM sd

/*
* define CSF value for HAB
*/
CSF 0x2000

/*
* Device Configuration Data (DCD)
*
* Each entry must have the format:
* Addr-type Address Value
*
* where:
* Addr-type register length (1,2 or 4 bytes)
* Address absolute address of the register
* value value to be stored in the register
*/

/* Enable all clocks */
DATA 4 0x020c4068 0xffffffff
DATA 4 0x020c406c 0xffffffff
DATA 4 0x020c4070 0xffffffff
DATA 4 0x020c4074 0xffffffff
DATA 4 0x020c4078 0xffffffff
DATA 4 0x020c407c 0xffffffff
DATA 4 0x020c4080 0xffffffff

DATA 4 0x020E04B4 0x000C0000
DATA 4 0x020E04AC 0x00000000
DATA 4 0x020E027C 0x00000030
DATA 4 0x020E0250 0x00000030
DATA 4 0x020E024C 0x00000030
DATA 4 0x020E0490 0x00000030
DATA 4 0x020E0288 0x00000030
DATA 4 0x020E0270 0x00000000
DATA 4 0x020E0260 0x00000030
DATA 4 0x020E0264 0x00000030
DATA 4 0x020E04A0 0x00000030
DATA 4 0x020E0494 0x00020000
DATA 4 0x020E0280 0x00000030
DATA 4 0x020E0284 0x00000030
DATA 4 0x020E04B0 0x00020000
DATA 4 0x020E0498 0x00000030
DATA 4 0x020E04A4 0x00000030
DATA 4 0x020E0244 0x00000030
DATA 4 0x020E0248 0x00000030
DATA 4 0x021B001C 0x00008000
DATA 4 0x021B0800 0xA1390003
DATA 4 0x021B080C 0x00000000
DATA 4 0x021B083C 0x01380134
DATA 4 0x021B0848 0x40404244
DATA 4 0x021B0850 0x40405050
DATA 4 0x021B081C 0x33333333
DATA 4 0x021B0820 0x33333333
DATA 4 0x021B082C 0xf3333333
DATA 4 0x021B0830 0xf3333333
DATA 4 0x021B08C0 0x00921012
DATA 4 0x021B08b8 0x00000800
DATA 4 0x021B0004 0x0002002D
DATA 4 0x021B0008 0x00333030
DATA 4 0x021B000C 0x676B52F3
DATA 4 0x021B0010 0xB66D8B63
DATA 4 0x021B0014 0x01FF00DB
DATA 4 0x021B0018 0x00201740
DATA 4 0x021B001C 0x00008000
DATA 4 0x021B002C 0x000026D2
DATA 4 0x021B0030 0x006B1023
DATA 4 0x021B0040 0x00000047
DATA 4 0x021B0000 0x83180000
DATA 4 0x021B001C 0x02008032
DATA 4 0x021B001C 0x00008033
DATA 4 0x021B001C 0x00048031
DATA 4 0x021B001C 0x15208030
DATA 4 0x021B001C 0x04008040
DATA 4 0x021B0020 0x00000800
DATA 4 0x021B0818 0x00000227
DATA 4 0x021B0004 0x0002552D
DATA 4 0x021B0404 0x00011006
DATA 4 0x021B001C 0x00000000

[Yuri]

Hello,

https://community.nxp.com/message/853686 

Regards,

Yuri.

[kinezo]

Hi Yuri, I went through the forum thread you sent.

We're currently booting off EMMC, so I don't think his SDP issue should be affecting us.