Getting HAB_INV_ASSERTION on imx Kernel

[paul_holmquist]

Got authentication of u-boot.imx working but now trying to extend to authenticating uimage.imx but getting error.

I followed both Appendix G of AN4581_i_mx6_secure_boot.pdf and the Yocto Workshop (DOC332479) but getting the following HAB error:

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

=> fatload mmc 1 0x12000000 /cp.uimage
reading /cp.uimage
19759136 bytes read in 945 ms (19.9 MiB/s)
=> hab_auth_img 0x12000000 0x12D6000

 hab_enabled() call bypassed...
   Authenticating image from DDR location 0x12000000...
ivt_offset = 0x12d6000, ivt addr = 0x132d6000
Dumping IVT
132d6000: 402000d1 12000000 00000000 00000000    .. @............
132d6010: 00000000 132d6000 132d6020 00000000    .....`-. `-.....
Dumping CSF Header
132d6020: 415000d4 000c00be 00001703 50000000    ..PA...........P
132d6030: 020c00be 01000009 90040000 000c00ca    ................
132d6040: 001dc501 e4070000 000c00be 02000009    ................
132d6050: e8090000 001400ca 001dc502 3c0d0000    ...............<

Secure boot disabled

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

Calling authenticate_image in ROM
    ivt_offset = 0x12d6000
    start = 0x12000000
    bytes = 0x12d8020
=> hab_status

Secure boot disabled

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------
event data:
    0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
    0x00 0x00 0x00 0x00 0x13 0x2d 0x60 0x00
    0x00 0x00 0x00 0x20
=>

Decoding above follows the same error example in Appendix A of HAB4_API.pdf that came with CST 3.0.1 which I'll restate as follows:

An assertion event means that one of
the following required areas is not signed as documented in the Operation section for
authenticate_image() API:
• IVT;
• DCD (if provided);
• Boot Data (initial byte - if provided);
• Entry point (initial word).

I followed all the steps as indicated for the Yocto workshop (4.2.2) except my kernel does not have a device tree (using Green Hills Integrity OS).  Recap of the steps:

1. Pad unsigned uimage.imx to 4K boundary
2. Generate IVT for uimage.imx (./genIVT.pl ivt12.bin 0x12000000 0x132D6000 0x132D6020)

3. Append IVT to unsigned image (uimage-pad-ivt.imx).
   

4. Sign using CST generating csf.bin (CSF script given below)

5. Pad csf.bin to 0x2000

6. Append csf-pad.bin to uimage-pad-IVT.imx
   

I was assuming that the CST tool takes care signing the four areas in step 4 above since I didn't get this error for a signed u-boot-signed.img? If not, done by CST tool, where are the instructions to make sure they are signed?

Here is my CSF script used in step 4 above:

[Header]
Version = 4.1
Security Configuration = Open
Hash Algorithm = SHA256
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS
Engine = CAAM

[Install SRK]
File="../crts/SRK_1_2_3_4_table.bin"
Source Index = 0

[Install CSFK]
File="../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate CSF]

[Install Key]
Verification Index = 0
Target Index = 2
File="../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate Data]
Verification Index = 2
Blocks = 0x12000000 0x00000000 0x12D6000 "uimage-pad-ivt"

[paul_holmquist]

Still waiting for help on this one.  The API states 4 possible issues but there is no HAB documentation that I can find for how each one would be fixed/addressed.... something in the CSF script (block statement values perhaps).  I don't have DCD so that should not apply.  Not sure what's mean't by "Boot Data" or when it would apply and how to fix.  How is this different the "Entry-Point" which I would think applies here but not clear on how to fix the issue either... this can't be the same Entry-Point listed in the mkimage output since that comes much later in boot process, right?

Thanks.

[Yuri]

Hello,

  You are right, the assertion event means that one of the following required

areas is not signed as documented in the Operation section for

authenticate_image() API:

• IVT;

• DCD (if provided);

• Boot Data (initial byte - if provided);

• Entry point (initial word).

  For Your case, below is the data block that does not have a required valid

signature:

Address Event 1 is 0x132d_6000

Length Event 1 is 0x20

  Check if IVT area is (correctly) signed.

Have a great day,

Yuri

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

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

[paul_holmquist]

Yes but "how" do I check that the IVT was signed correctly... am I suppose to decode the CSF binary... if so likely need more instructions on that?  Doesn't the CST automatically include that signing when it produces the CSF binary?  Or does the CSF input script need to specify that (yocto example CSF script does not which is why I am assuming this done automatically)?  I've attached my resulting csf binary file (csf12a.bin) if you tell me how to decode where the signature is for IVT and how it was computed... (was it signed as a hash of the IVT bytes, etc.).

Would this have any relation to the fact that our "mkimage" call places the Load Address to 0x14000000 due to attaching elf-loader but our u-boot still loads to 0x12000000?  See below:

Found loader image: /home/GHSIntegrity/arm_elfloader.bin
Final image created successfully: kernel.elf
Output from Integrating kernel.gpj:
mkimage version dub-2015.04-r12.1-g5ea79be-dirty
Output from Integrating kernel.gpj:
Image Name:   INTEGRITY
Created:      Tue Sep 25 07:50:51 2018
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    19748540 Bytes = 19285.68 kB = 18.83 MB
Load Address: 14000000
Entry Point:  14000000
Done

As I understand the elf-loader that is added to the front of the uimage relocates/moves the uimage to 0x14000000 after our u-boot script loads it to 0x1200000 before calling bootm.  I was assuming that bootm performs HAB checks at this original u-boot load-address before bootm passes on execution to the elf-loader that is embedded in the front of your uimage.

[Yuri]

Hello,

  Generally Your sequence is correct. Please check parameters, addresses, values just for 

Your case, using  description of the CSF commands in the CST documentation (HAB Code-Signing

Tool User’s Guide).

 i.MX High Assurance Boot Reference Code Signing Tool 

Regards,

Yuri.