HAB u-boot issue in colibri-imx6ull

Hi team,

I’m trying to work on the security side and want to implement HAB in my imx6ull module.

I’m using below thread for reference : link text

Problem is that after using same step I’m able to generate u-boot.imx file but not able to get IVT data address or Image size. Also attaching u-boot build log and my .csf file. link text

od -X -N 0x20 u-boot.imx

0000000 00000000 00000000 00000000 00000000
*
0000040

Due to above Error i’m not able to write correct value in .csf file for authentication.

What is the issue here that i’m not getting any output for above command as per NXP document.

Is my u-boot version 2016.11 is ok for HAB testing ??

Regards,

Hitendra prajapati

Greetings @hitendra_prajapati,

Are you using our U-Boot source? If you compiled it correctly there should be a u-boot-nand.imx binary which is the “proper” binary that gets used on our i.MX6ULL platform. The u-boot.imx binary is just an intermediate binary.

The nand binary is what you want to run the command on to get the proper IVT header.

Best Regards,
Jeremias

Hi

check the output of od -X u-boot-nand.imx|less in attachment.

link text

Hi @jeremias.tx,

I have compile u-boot via bibake command of yocto build.

Did not take a separate clone and cross compile.

Check the output of my hab_status command on u-boot and also other attached file. link text

fuse table : link text

Please suggest what is the issue here ? I can able to boot with signed binary but got error in hab_status command check in attached log.

Note : Due to error, I did not close the device via fuse command.

Regards

Hitendra

@hitendra_prajapati

I don’t immediately see anything wrong with your CSF. Just to confirm while you did not burn the fuse to close the device, did you burn the fuses to flash your key values to the device? Based on the output from your hab_status it simply seems that the signature/key check was invalid. So initial assumption is that something either the fuses or u-boot binary weren’t signed correctly.

Also could you try building the U-Boot binary outside of yocto via our source. The way you’re doing it should work but I just want to eliminate any unforeseen variable from the yocto build. Instructions to build U-Boot separately can be found here.

Hi @jeremias.tx,

Yes,I can try to build u-boot and check again.

I burn the fuses based in the value given by SRK_1_2_3_4_fuse.bin table .

Regards,
Hitendra

Hi @jeremias.tx ,

I tried what you suggested but still i got the same error.

Please check all the attached code and keys and try with your end. Share the result with me.

from the attached log can you identify that the fuses program correctly or not.

link text

Regards,

Hitendra

Hi @hitendra_prajapati

Yes I can confirm on my end that I get the same authentication error as you. However I dug a bit into it and I think I may have found a cause. See the following NXP application note: https://www.nxp.com/docs/en/application-note/AN4581.pdf

On page 12 there is a note that due to a issue with the i.MX6ULL processor the Engine field in the CSF needs to be set to SW.

I believe this is worth a shot, I was going to try and confirm this on my end but it seems I don’t have some of your key files needed to recompile and resign. Also I’ve already fused your key values onto my i.MX6ULL so I can’t really attempt with my own certs…

Best Regards,
Jeremias

Hi @jeremias.tx

Thank you for your effort on this.

I will try that solution on my end also and let you know.

I already provided all the key in the last zip file. You can use that and I’m attaching the same. link text

Regards,
Hitendra

Hi @jeremias.tx

I tried your suggestion of engine=SW but still got the same error

Please check at your side and revet.

Regards, Hitendra Prajapati

Hi @hitendra_prajapati,

Unfortunately I was able to recreate the issue on my end. I even redid the whole process from scratch using my own keys/certs on a different module. I believe this issue might be outside my expertise as I and us at Toradex in general aren’t too familiar with the inner workings of HAB.

I’d suggest approaching NXP with the issue and see if they can provide any information.

@gasmbas on the community if they could respond as I recall they were able to get HAB working on the i.MX6ULL with no HAB Events.

Best Regards,
Jeremias

Hi @jeremias.tx @gasmbas

Thank you for your support.

I’m following the thread (HAB u-boot cannot boot) of @gasmbas to use HAB in imx6ull, but using the same step also i got the error as above.

I checked the openssl version is : OpenSSL 1.0.2g 1 Mar 2016 which is mention by you.

Linux version : Linux CI5LUB051720 4.15.0-76-generic #86~16.04.1-Ubuntu
SMP Mon Jan 20 11:02:50 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

@gasmbas can you help me to solve this issue.

Regards,
Hitendra

Hi @jeremias.tx @gasmbas

One thing i noticed that if i’m using CSF file that you showed me in @gasmbas
thread

# Address Offset Length Data File Path Blocks = 0x877ff400 0x00000000 0x00089c00 "./u-boot-nand.imx"

i’m getting below error :

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

Invalid Block arguments, Blocks start offset and length together exceed file size in command AuthenticateData

While i’m using the below block and able to generate u-boot.csf.bin successfully.

Address Offset Length Data File Path Blocks = 0x877ff400 0x00000000 0x00088c00 "./u-boot-nand.imx

I did not understand why i’m getting
error for you CSF file even though I
followed the every step of yours
.

Can you explain this.

Regards,
Hitendra

Hi @hitendra_prajapati,

That was one issue me and @gasmbas could never quite explain. For some reason when I compile the Toradex U-Boot source the “Length” field given by Hab Blocks was different from what gasmbas experienced. It seems to be the same issue in this case.

I still do urge you though to also pose this question to NXP on their community forums as they’d have greater experience with HAB.

Best Regards,
Jeremias

Hi @jeremias.tx

I have raise a ticket on NXP community and waiting for response.

Regards, Hitendra

Ok, let us know once you got an answer.