Problems with i.MX28 High Assurance Boot

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problems with i.MX28 High Assurance Boot

7,819 Views
christopherpres
Contributor III

Hi,

 

I’ve got a problem with using High Assurance Boot (HAB) on my i.mx28 using U-boot (version 04/2012).

When booting, I get several HAB failure events (described later on) and I don’t know what to do about it and how to interpret them in detail. I’ll first give the general steps which I applied to get HAB running and I attached my source files.

 

I followed the instructions from several Freescale manuals:

  • I generated keys/certificates with the hab4_pki_tree script from the Code-Signing Tool (CST) package as described in the “HAB Code-Signing Tool” documentation
  • I generated the e-fuse hash and the SRK table as described in the “HAB Code-Signing Tool” documentation
  • I programmed the e-fuse hash into the i.mx28 by using the otp_burner and the BitInit Tools
  • I checked with the BitBurner Tool if the fuses were actually set à I could see the fuse hash value with the tool, so I assume up until this step everything went fine.
  • I modified the u-boot Linker File (.lds) to reserve a section for the code signature as described in the “Secure Boot with i.MX28 HAB v4” documentation (page 15)
  • I call the HAB report_event() function from the ROM Vector Table in the U-Boot Source to get HAB Debug output
  • I compiled my U-Boot with the mx28 config from Denx to obtain: u-boot (ELF file), u-boot.bin (Binary), u-boot-spl (ELF), u-boot.bin (Binary). The spl program is some kind of first-stage bootloader which is called before u-boot
  • I wrote a CSF File for u-boot.bin and one for u-boot-spl.bin. I wrote the file as explained in the “HAB Code-Signing Tool” documentation and end up with files which are pretty much the same as the example given at page 27 of the “Secure Boot with i.MX28 HAB v4” documentation
  • I used the CST to create the signatures of u-boot.bin  and u-boot-spl.bin
  • I modified the u-boot.bd file to load the signature
  • I ran elftosb to create my boodable sb-File

 

When booting, I get the following HAB Errors:

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

event data:

    0xdb 0x00 0x14 0x40 0x33 0x22 0x33 0x00

    0x00 0x00 0x00 0x0f 0x00 0x00 0x00 0x00

    0x00 0x00 0x07 0x50

 

--------- HAB Event 2 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x22 0x33 0x00

    0x00 0x00 0x00 0x0f 0x00 0x00 0x80 0x00

    0x54 0xce 0x13 0xdd

 

--------- HAB Event 3 -----------------

event data:

    0xdb 0x00 0x08 0x40 0x33 0x22 0x0a 0x00

 

--------- HAB Event 4 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x00

    0x00 0x00 0x00 0x20

 

--------- HAB Event 5 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x14

    0x00 0x00 0x00 0x04

 

--------- HAB Event 6 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x22 0x33 0x00

    0x00 0x00 0x00 0x0f 0x00 0x00 0x80 0x00

    0x54 0xce 0x13 0xdd

 

--------- HAB Event 7 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x00

    0x00 0x00 0x00 0x20

 

--------- HAB Event 8 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x22 0x33 0x00

   0x00 0x00 0x00 0x0f 0x04 0x10 0x00 0x00

    0x00 0x00 0x03 0xe8

 

My questions are:

  • Are the general steps I described above correct, or did I miss something?
  • How do I interpret the HAB events? I know that the HAB API documentation provides some information about that, however if I analyze the first event with the HAB API documentation I obtain the information that the check_target() function accessed an invalid address. The check_target function was called with the following parameters (according to the HAB debug output):
    • Type of target: 0x00 0x00 0x00 0x0f (the documentation says that this is HAB_TGT_MEMORY and that the memory white list has to be checked à what does that mean?)
    • Address of target region: 0x00 0x00 0x00 0x00
    • Size of target region: 0x00 0x00 0x07 0x50

          With just this information I have no idea where I should start and what to do

  • Am I correct that I do not manually have to create an Image Vector Table (IVT) as described by the “Secure Boot with i.MX28 HAB v4” documentation on page 16? The “Using elftosb to generate HAB enabled boot streams” documentation says that the IVT is created by a command in the bd file (which I use in my attached bd-file). So does this mean that the “Secure Boot with i.MX28 HAB v4” documentation is not up-to-date? How should I now include the IVT? With the command in the bd-File or by manually linking a section into the binary (as described in “Secure Boot with i.MX28 HAB v4”)?
  • Should HAB also work if I do not modify the linker file of U-Boot, but just load the signature to any free area in the memory (and of course reference this address in the bd-file)?
  • Do the source files I provide with this posting look correct?
  • Did anybody our there get HAB working? Is there an example (full source code) available?


I'm really stuck here and I appreachiate any kind of help very much.


Best regards,

Christopher

Original Attachment has been moved to: u-boot.lds.zip

Original Attachment has been moved to: uboot-csf.zip

Original Attachment has been moved to: u-boot-spl.lds.zip

Original Attachment has been moved to: u-boot.bd.zip

Original Attachment has been moved to: spl-csf.zip

Labels (1)
Tags (2)
32 Replies

1,348 Views
haiqingbai
Contributor I

Hi, Tai:

      Sorry I forgot to put the link files into the attached zip file. That's very kind of you.

      For power_prep, boot_prep and uboot's link files, I only added below lines before bss section:

SECTIONS

{

-    . = 0x00000000;

+   . =  0x00000010;

...

+     __uboot_ivt = .;

+    .ivt : { KEEP(*(.ivt)) }

+    __hab_uboot_data = .;

+    .hab : { KEEP(*(.hab)) }

+    . = . + 0x2000;

.bss

  My questions are: 1. according with your suggestion, for example, I need to add " align(0x4010) before  "__hab_uboot_data = ." ?

2. I found the "BASE_ADDR" in AN4555 which is passed by Makefile, I do not know what it's mean and do not want to use it, Tai,

can I ignore it?  I also found in Chris' patch, the BASE_ADDR in u-boot-spl.lds is "0x00000100", but int u-boot.lds, it is "0x40000100",

3. If I used the above image layout, pad to 0x4000, in csf: block 0x10 0x0 0x4000 "xxx_pad.bin", do you think the "ivt" is in the signed block?

Tai, thanks your help again, I am in a urgent work, could you please share your linker, csf and .bd files for reference? My email: wrlucker@sina.cn or

haiqing.bai@gmail.com.

0 Kudos

1,348 Views
tainguyen
Contributor III

try this

SECTIONS

{

   . =  0x00000010;

_BASE__ = .

    __uboot_ivt = .;

    .ivt : { KEEP(*(.ivt)) }

. = _BASE__ + 0x4000;


    __hab_uboot_data = .;

    .hab : { KEEP(*(.hab)) }

    . = . + 0x2000;

.bss

objcopy -I binary -O binary --gap-fill 0xff --pad-to 0x4000 old.bin pad.bin

Then, in your csf file

Blocks = 0x000010 0x0 0x4000 "pad.bin"

my bd file is exactly as in chris's patch.

0 Kudos

1,348 Views
haiqingbai
Contributor I

Dear Tai:

You are right, I am here now:

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

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x41 0x02 0xf4 0x1c

    0x00 0x00 0x00 0x20

--------- HAB Event 2 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x41 0x00 0x80 0x00

    0x00 0x00 0x00 0x04

You mentioned that "include the IVT in the to be signed block",  I think the error image is uboot, power_prep and boot_prep are ok now.

Tai, I tried lots times to make the IVT signed, but maybe I am wrong way, the above Events still there, could you please give me some

hints? o, lots, lots of thanks ^_^; (attached link and csf of uboot.)

0 Kudos

1,348 Views
tainguyen
Contributor III

Bai,

You need to do the same thing for uboot. After compiling uboot, there is a uboot.map file. Look in there to figure out how big uboot will be. Then, use that as your ceiling to pad to the next 0x1000 alignment to make thing easy.  Also, your BASE now will be 0x40000010.The rest you already know.

Tai

0 Kudos

1,348 Views
haiqingbai
Contributor I

Tai:

      The .map file is very useful to diagnose, thanks a lot!  :smileyhappy:

0 Kudos

1,348 Views
rajvihar
Contributor I

Hi tainguyen , christopherpreschern Deactivated user,

I have been trying to setup secure boot on i.MX28.

    - I have followed all the steps in AN4555 to generate keys/certs, blow them and verify that they are blown using the BitBurner Tools.

    - Applied HAB Patches to u-boot and u-boot-spl as instructed and discussed above in the thread.

    - I have modified linker files and .bd files accordingly

Even before padding and code-signing them image, I have tried to boot the unsigned .sb file on the device.


When I download the .sb using mxsldr onto the device it fails to transfer the the .sb file completely and the boot process fails. This happens only when I change the load address of u-boot-spl to a non-zero address (0x10 from 0x00). When the load address is 0x00 the boot process is successful and the boot-loader and kernel load but with HAB Events(as expected because the image isn't signed yet.)

I have attached the the changes I have done.

I am really stuck and any help in resolving this is very much appreciated.

Thanks,

-Raj

0 Kudos

1,348 Views
weo
Contributor I

I  exactly see that, too. The system crashes when the SPL is linked to an address above zero. I added to the .bd file (before the call to the SPL):

     load 0x00.b >0x04..0x0f;

This clears the vector table. I have no idea why that helps, but I really would like to know.

0 Kudos

1,348 Views
tainguyen
Contributor III

Bai,

I don't use the imx tool to write the OTP. I use an OTP linux driver( links below ). However, I do use the bitburner tool to read back and verify the content of the OTP registers just to make sure.

https://community.freescale.com/thread/306284

https://community.freescale.com/thread/294307

Edit: I started again with a new board.  The Otp_burner.py gave me the same error but works on Windows XP. Using the window tools, I am able to generate OtpBit.sb with the srk_fuse.bin and burn it using the BitInit.exe tools. I am now passed the Install Key errors. I would recommend you do the same to save time. However, I am getting a new error which has to do with authentication. If I get this far, then I assume that the board successfully verify the SRKs, install the SRK table and used is  using it to verity the boot image.

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

event data:

    0xdb 0x00 0x1c 0x40 0x33 0x18 0xc0 0x00

    0xca 0x00 0x14 0x00 0x02 0xc5 0x00 0x00

    0x00 0x00 0x0d 0x34 0x00 0x00 0x01 0x00

    0x00 0x00 0x20 0x00

--------- HAB Event 2 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x1d 0x5c

    0x00 0x00 0x00 0x20

--------- HAB Event 3 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x14

    0x00 0x00 0x00 0x04

0 Kudos

1,348 Views
tainguyen
Contributor III

Thank you. I did generated a length of 4096. Let me find another board and try again. Again, really appreciate your  help.

0 Kudos

1,348 Views
tainguyen
Contributor III

Chris,

This is excellent. Thank you for addressing my questions. You rock.

Tai

0 Kudos

1,348 Views
dwc
Contributor II

Thanks for the reply.  It looks like you did something special to make the linker work well.

Did you happen to go any further with staged authentication using the API from within U-boot?

Edit to add lessons learned (for a lack of better place to communicate this):

For those attempting to using the HAB API from within U-boot, I highly recommend flushing your data caches before making any calls to the HAB API.  It seems that in some cases of DMA transfers, the data is not fully synced between the cache and RAM.  At the point of making the HAB API call to verify a signature over data in RAM, HAB attempts to use RAM data that is not actually valid.  The HAB failure returned indicates a signature verification problem but with a NOP context.  U-Boot provides a nice CONFIG_CMD_CACHE switch to enable cache flushing from the interactive console.

1,348 Views
christopherpres
Contributor III

I don't use the U-Boot API. After U-Boot I simply boot a signed kernel. I use the mkimage tool and the bootm command.

0 Kudos