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,805 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

2,694 Views
christopherpres
Contributor III

what I forgot to mention: When booting with an unsigned image, I get pretty much the same HAB errors as described above.

Does anybody know what they mean?

Best regards,

Chris

HAB Errors when booting with an unsigned image:

--------- 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 0x08 0x40 0x33 0x22 0x0a 0x00

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

event data:

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

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

    0x00 0x00 0x00 0x20

--------- HAB Event 9 -----------------

event data:

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

    0x00 0x00 0x00 0x00 0x40 0x00 0x01 0x00

    0x00 0x00 0x00 0x04

--------- HAB Event 10 -----------------

event data:

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

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

    0x00 0x00 0x03 0xe8


0 Kudos

2,694 Views
Yuri
NXP Employee
NXP Employee

All appears working with manually linking the IVT into the binary as described in AN4555.

2,694 Views
christopherpres
Contributor III

Yes, everything works fine now:

Here is what was wrong and what I changed to make it work:

  • I tried to create the IVT with the bd-Script and elftosb. This did not work and now I create the IVT as described in AN4555
  • My U-Boot uses a pre-boot-loader (uboot-spl). This pre-boot-loader was loaded to 0x0 in memory. I modified this to be loaded to 0x100 in the corresponding .lds file and in the .bd file
  • I manually created the IVT with a hardcoded header (0xD1002040). This was a problem, because this value is converted to little-endian and according to the i.MX28 reference manual, the IVT header has to be stored in big-endian format - I changed the IVT-header value in the code to 0x402000D1 and now it works.

2,694 Views
dwc
Contributor II

I'm at a bit of a stuck point myself.  Do you have any tips for working out the errors?  I'm following basically the same approach as you.  I am down to 3 HAB Events that look similar to ones in your first post. The first is an Invalid address during authenticate_image().  The next two are assertion errors that cover the code of the IVT and the _start function in uboot.  Did you run into any issues as you worked out your errors?  Doing a memory dump of the IVT location appears that all the field values are correct.

HAB Configuration: 0xf0, HAB State: 0xf0

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

event data:

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

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

event data:

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

        0x00 0x00 0x00 0x00 0x40 0x06 0x0c 0x18

        0x00 0x00 0x00 0x20

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

event data:

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

        0x00 0x00 0x00 0x00 0x40 0x00 0x01 0x00

        0x00 0x00 0x00 0x04

0 Kudos

2,694 Views
christopherpres
Contributor III

hhmmmm.....difficult to say...

- How do you create the IVT? Do you add the code and modify the linker files as described in AN4555 or do you use the elftosb-Tool to create the IVT?

- can you post the HAB-relevant code? The linker files, the bd-File and the file where you include the IVT?

0 Kudos

2,694 Views
dwc
Contributor II

I appreciate the feedback.  I don't know if having two IVT structures defined is necessary, but I'm having linking issues without hardcoding values for __hab_data and __hab_data_end for the full u-boot compilation.  The spl build resolves the symbols just fine.

Also, my uboot csf looks like this, so the input_uboot_ivt and _start should be covered by the signature.

[Authenticate Data]

    Verification index = 2

    Blocks = 0x40000100 0x0 0x76000 "u-boot-mx28-tosign.bin"

EDIT:

The errors were due to linking problems.  The outlined steps in AN4555 were failing to link properly for me at the moment.  Hardcoding addresses solved the issue but this is highly error prone.  If others experience the same problems I suggest double checking the linking output.

0 Kudos

2,694 Views
christopherpres
Contributor III

that means it works now?

Here are my linking-related HAB-files. Except for BASE_ADDRESS I have no hardcoded addresses.

0 Kudos

2,693 Views
tainguyen
Contributor III

Hi Chris,

I have a beginner question for you. I am learning Uboot while trying to do HAB. I am trying to boot a version of uboot from Jan, 2013. I applied your patch which modified /arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd, arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds, arch/arm/cpu/u-boot.lds. However, I don't know where to add the hab-changes code. The only IVT header I could find in my uboot src is in the imximage.h which look different than yours.

Also, I notice that the address reserved for the patch is 0x100 instead of 0x10 as described int he AN4555. And your patch does not have any reference to BASE_ADDR which seems to be for reserve some padding. Do we need that extra padding? Is that only for future growth?

Thank you for your time.

Here is the ivt in the imximage.h

typedef struct {

  ivt_header_t header;

  uint32_t entry;

  uint32_t reserved1;

  uint32_t dcd_ptr;

  uint32_t boot_data_ptr;

  uint32_t self;

  uint32_t csf;

  uint32_t reserved2;

} flash_header_v2_t;

0 Kudos

2,693 Views
christopherpres
Contributor III

I added the rest of my code changes to make things a bit clearer. However, I was asked to replace any reference to the specific board I use. Therefore you'll find "COMPANY" and "PROJECT" in the files paths. Adapting the patch to the /boards/denx/m28evk/ board should work.

- I don't use the "imximage.h" IVT definition (I didn't know there is such a thing - I would have been prettier though to use it)

- Yes, my linker start-address is 0x100 and not 0x10 as described in AN4555. There is no reason for that - you can use anything != 0x0.

- I do have a BASE_ADDRESS in my "hab-changes code". In AN4555 this BASE_ADDRESS is also used, but it is defined in a Makefile if I remember correctly. I didn't want to touch the Makefile, therefore I define it in the code.

0 Kudos

2,693 Views
tainguyen
Contributor III

Chris,

I applied your new patch to modify the lds files, spl_boot.c, and <myproject>.c. I also have an identical bd file. I am able to create the u-boot.sb following directions. Now, I am getting similar HAB status to when you started.  I am working on getting information to interpret the statuses. Mean while, I hope you can point out something obvious that I am doing wrong.

Here are my steps to create u-boot.sb

1) I followed the AN4555 to create and burn the SRKs to the OTP registers. The board is still in Open HAB configuration.

2) build u-boot to create u-boot-spl.bin and u-boot.bin, padded them to next block of 4096 to create u-boot-spl_pad.bin and u-boot_pad.bin. I use a cross compiler tool like this:

   arm-none-linux-gnueabi-objcopy  -I binary -O binary --gap-fill 0xFF --pad-to 0x6B000 u-boot.bin u-boot_pad.bin

3) I create similar csf file as in AN4555 and sign the padded binary as follow:

     ../linux/cst -o signature_uboot < uboot.csf

Here is and example of the Authentication Data in the CSF:

[Authenticate Data]

  Verification Index = 2

  Engine = DCP

  Blocks = 0x40000100 0x0 0x6B000 "u-boot_pad.bin"

4) Then create the u-boot.sb using the bd file. The bd is identical to yours since I have a similar set up: u-boot-spl then u-boot.

  elftosb -zf imx28 -c u-boot-imx28.bd -o u-boot.sb

Here are the status I am getting:

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

event data:

    0xdb 0x00 0x14 0x40 0x33 0x21 0xc0 0x00

    0xbe 0x00 0x0c 0x00 0x03 0x17 0x00 0x00

    0x00 0x00 0x00 0x48

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

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

event data:

    0xdb 0x00 0x14 0x40 0x33 0x21 0xc0 0x00

    0xbe 0x00 0x0c 0x00 0x03 0x17 0x00 0x00

    0x00 0x00 0x00 0x48

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

event data:

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

    0x00 0x00 0x00 0x00 0x40 0x06 0xb0 0x00

    0x00 0x00 0x00 0x20

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

event data:

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

    0x00 0x00 0x00 0x00 0x40 0x00 0x01 0x00

    0x00 0x00 0x00 0x04

0 Kudos

2,693 Views
christopherpres
Contributor III

Your 1. error says that you have an invalid certificate. Perhaps your RSA key is too long? According to AN4555 the imx28 just supports 1024 or 2048 bit keys. Otherwise perhaps try to start from the beginning with generating the keys/certificates. Regarding certificate/key generation I followed AN4555 and the CST manual and that worked.

best regards,

Christopher

0 Kudos

2,693 Views
haiqingbai
Contributor I

hi,  Chris:

       I also got the same HAB events code like Tai got,  but I really used 2048bit length.  Is there any other reason to cause this issue?  Can I say that when I saw the events "0x33 0x21 0xc0 0x00 ",  it means that all the linker and hab data's address are ok at least?   thank you very much!

B,R

Hq Bai

0 Kudos

2,693 Views
tainguyen
Contributor III

Hq Bai,

According to the HAB4_API, you and I are having problem with the certificate. The code indicate that we have invalid certificate. I am not sure if the hab data addresses are correct since the board will continue booting at *entry even if it failed HAB authentication, in open configuration. I am going off the assumption that it is correct since Chris had tested it. I am reviewing and verifying my certificates. I'll send update if I find anything. I also generated 2048 as the example in the "HAB Code-Signint Tool User's Guide".

tai

0 Kudos

2,693 Views
haiqingbai
Contributor I

Tai:

    Thanks your quickly reply!   The other thing need your great help:  for fuse the SRK hash value, I used the windows tool "imx_otp_tools\BitBurner_1.0.6.0",  it failed to write, then I switch to otp_burner.py mentioned in AN4555,

   "otp_burner.py --srk srk_fuses.bin --key encryption_key.txt –i bit_settings.txt –o otp_init.sb", the document says that the key is "ROM uses in decrypting the boot image", "bit_settings.txt" is "carries values for other fuses", I just

want to fuse the SRK hash, so I just echo "*chip-family-mx28* into bit_settings.txt and run "./otp_burner.py --srk SRK_fuse.bin -i bit_settings.txt -o otp_init.sb", the error is :

Traceback (most recent call last):

  File "./otp_burner.py", line 1545, in <module>

    OTPGeneratorTool().run()

  File "./otp_burner.py", line 1428, in run

    bits.fillInSuperRootKey(options.superRootKeyPath)

  File "./otp_burner.py", line 1003, in fillInSuperRootKey

    srkWordValue, = struct.unpack('L', srkWordBytes)

struct.error: unpack requires a string argument of length 8

Which tool did you use to fuse the SRK hash?  Could you please correct me for above?   thanks!

B,R

Bai

0 Kudos

2,693 Views
tainguyen
Contributor III

Bai,

It is working for me now.

These info might be helpful for you:

1) I use Chris' patch. I had to make some update regards to _hab_data addresses to work with my board.

2) use the CST tools to generate the signatures

3) sign and pad the image according to the AN4555

4) on a windows XP machine: run otp_burner.py and feed it the srk_fuse.bin and the bit_settting.txt. This spit out the OtpBit.sb

5)  on a windows XP machine: use bitinit.exe to burn the OtpBit.sb

6) flash your signed boot images.

Good luck,

Tai

0 Kudos

2,693 Views
haiqingbai
Contributor I

Yes, Tai, highly appreciate your great help. To make opt_burner.py work, the os should be xp and the python's version should be care for. Now same as you, I got "0x33 0x18 0xc0 0x00" HAB events. I can not fully use Chris's patch because I use the patched uboot(2009.08 version.). I believe the hab address caused this issue like you mentioned,

but I have not resolved it.

0 Kudos

2,693 Views
tainguyen
Contributor III

Bai, I think you are almost there. If  you are having addressing issue, follow AN455 section 3.3 to configure the linker and register the ivt section. The rest of the errors should tell you which section of data is not signed. This is probably because the HAB_data address section and your csf file might not match. You just need to adjust or do some padding if needed. If you post the rest of the error, I can try to point out something.

tai

0 Kudos

2,693 Views
haiqingbai
Contributor I

Hi, Tai:

I use “imx-bootlets”  and uboot(2009.08) which has been patched to support i.mx28. So there are “power_prep”, “boot_prep” and “uboot”  images need to be verified.

  1. I added IVT header one per image like you and Chris did on “u-boot-spl” and “uboot” image.  I added almost same codes for power_prep, boot_prep and  uboot like

         attached “same-code-changes.txt”.  The only difference is in mx28_evk.c,  the  “BASE_ADDR” is defined as “0x40000010”.(Actuall “TEXT_BASE” in config.mk is “0x41008000)

   2.  Build three image and convert to binary with:

<cross-compile->objcopy -I elf32-little -O binary --gap-fill 0xFF <elf image>  <elf image>.bin

Then “ls”:

    76644  power_prep                             

    52259  boot_prep

    662978 u-boot

    160836 u-boot.bin

    10240  power_prep.bin

    6532 boot_prep.bin

Then I was confused on pad size and did below:

<cross-compile>objcopy -I binary -O binary --gap-fill 0xFF --pad-to 0x2A000 u-boot.bin u-boot_pad.bin

<cross-compile>objcopy -I binary -O binary --gap-fill 0xFF --pad-to 0x2000 boot_prep.bin boot_prep_pad.bin

  1. Generate CSF:

Power_prep.csf:

Blocks = 0x10 0x0 0x2800 "power_prep.bin"

Boot_prep.csf:

Blocks = 0x10 0x0 0x2000 "boot_prep_pad.bin"

  1. Uboot.csf:

Blocks = 0x41000010 0x0 0x2A000 "u-boot_pad.bin"

-rw-r--r-- 1 users 168K Nov 14 17:35 u-boot_pad.bin

-rw-r--r-- 1 users 8.0K Nov 14 17:35 boot_prep_pad.bin

-rw-r--r-- 1 users 3.9K Nov 14 17:39 power_prep_hab_data

-rw-r--r-- 1 users 3.9K Nov 14 17:39 boot_prep_hab_data

-rw-r--r-- 1 users 3.9K Nov 14 17:39 uboot_hab_data

  1. Use elftosb to create sb.

Then got “0x33 0x18 0xc0 0x00” events like the attached log.

  Tai, could you please help me to check where I am wrong?  Lot’s  thanks.

0 Kudos

2,694 Views
tainguyen
Contributor III

Bai,

What does your linker file look like?

Here is what I understand, and seems to work for me. For image the is less than 0x4000 bytes, I would gapfill and pad to 0x4000.

0x10 ------------------ Start offset

        DATA TO BE SIGNED/your boot image

0x4010 ------------------ Start of HAB data

       HAB DATA

0x6010 ------------------ End of HAB data

So in your linker file, you would have __hab_data set at 0x4000 from BASE offset. And your CSF file will specify that the BASE offset is 0x10 and the length of data to be signed is 0x4000. Remember to also include the IVT in the to be signed block. I had that error before.

The first error code said you have not signed code starting at address 0x10 for the length of 0x2800 bytes.

I hope this help.

tai

0 Kudos

2,694 Views
collinshi
Contributor II

Hi Tai,

Can you help to check my memory layout?

Is there anything I missed?

My csf file is copyed from the AN4555 sample. Only the [Authenticate Data] is different.

Mine is :

[Authenticate Data]

    Verification index = 2

    Engine = DCP

    Blocks = 0x00000010 0x0 0x004000 "ivt_XLDR_pad.nb0"

I am working on imx28 to security boot wince eboot.

eboot contains two part: xldr.nb0 and eboot.nb0

Using this memory layout, it always shows the HAB EVENT:

dispay_hab_event ,hab_event_number=1

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

   dispay_hab_event ,hab_event_length=0x8

    0xDB 0x0 0x8 0x40 0x33 0x28 0xA 0x0

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

0x28 0xA in the HAB_API_UG means : HAB_INV_CALL: hab_rvt.entry() not run successfully prior to call

1.jpg

0 Kudos