i.MX Processors中的主题 Re: Getting HAB_INV_ASSERTION on imx Kernel

Getting HAB_INV_ASSERTION on imx Kernel

paul_holmquist — Mon, 24 Sep 2018 17:00:39 GMT

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:

Pad unsigned uimage.imx to 4K boundary
Generate IVT for uimage.imx (./genIVT.pl ivt12.bin 0x12000000 0x132D6000 0x132D6020)
Append IVT to unsigned image (uimage-pad-ivt.imx).
Sign using CST generating csf.bin (CSF script given below)
Pad csf.bin to 0x2000
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"

Re: Getting HAB_INV_ASSERTION on imx Kernel

Yuri — Tue, 25 Sep 2018 04:53:37 GMT

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!

Re: Getting HAB_INV_ASSERTION on imx Kernel

paul_holmquist — Tue, 25 Sep 2018 13:38:00 GMT

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.

Re: Getting HAB_INV_ASSERTION on imx Kernel

paul_holmquist — Wed, 03 Oct 2018 19:16:42 GMT

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.

Re: Getting HAB_INV_ASSERTION on imx Kernel

Yuri — Fri, 05 Oct 2018 08:46:32 GMT

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.