imx6dl HAB u-boot.imx signature

[imx8mp_developer]

I am working on an imx6dl-powered custom hardware and I need to implement the HAB, as far as I noticed I have:
- SPL

- u-boot.imx

- kernel fitImage

The build is done using Yocto but the signature is done afterwards using a script I inherited from another project which is able to sign SPL, u-boot.img and kernel fitImage using CST tool, I am trying to use the same script for this project but I am not sure about the signature of u-boot.imx. The script is able to generate the IVT, the CSF, to pad and to concat the signature to the padded binary and so on, but in order to get the u-boot image size (used to computate load address, IVT address, CSF address) it does:

$(od -j 0x04 -N 0x4 --endian=big u-boot-image.bin -t x4 | sed -ne 's/0*04[[:space:]]/0x/p')


which I think is good for fitImages but not really for my u-boot.imx which is a:

dumpimage -l u-boot.imx  
Image Type:   Freescale IMX Boot Image
Image Ver:    2 (i.MX53/6/7 compatible)
Mode:         DCD
Data Size:    61536 Bytes = 60.09 KiB = 0.06 MiB
Load Address: 00907420
Entry Point:  00908000
HAB Blocks:   0x00907400 0x00000000 0x0000cc00
DCD Blocks:   0x00910000 0x0000002c 0x0000000

so, the question is, how to CST-sign a Freescale IMX Boot Image? How to properly generate IVT (which should already be present after Yocto build..) etc?

I also have a u-boot.img which seems to be a u-boot fitImage, but my project requires u-boot.imx

Moreover, yocto provides SPL.log (containing the HAB Blocks) but not a u-boot.log

Thanks in advance!

[Harvey021]

Referring to the section <10.9 Security reference design> of Linux User Guide 

Where we provide a tool as CST Signer that can help analyze BSP image for signing.  

Regards

Harvey

[imx8mp_developer]

Hello @Harvey021  and thanks for your reply,

it is very useful actually, but let's say that it would be a little long to integrate the changes into an already existing project...

So let's say that I already have a script coming from older projects which is able to sign:
- SPL (using SPL.log)

- u-boot.img  (I assume it's treated as u-boot fitImage since running "dumpimage -l" shows all the contents)

- kernel fitImage

which also generates the CSF and IVT and I need to adapt it to another project which makes use of u-boot.imx (also, in this case, should I care about SPL? Or u-boot.imx will include both!?)

I need a way to figure out if the signed files are OK or not (in terms of signature position and so on) before deploying them on a fused target..

For instance, I can run like:

cst-4.0.0/linux64/bin/hab4_image_verifier ../u-boot.imx.signed <offset>

and, if I use offset=0x0 I have:

File: ../u-boot.imx.signed
Offset: 0x0
Image Vector Table:
 Offset: 0x0
 IVT Tag: 0xD1
 IVT Version: 0
 IVT Length: 0x20
 HAB Version: 0x40
 Entry: 0x908000
 DCD: 0x0
 Boot Data: 0x907420
 Self: 0x907400
 CSF: 0x914000
Invalid CSF tag

While if I use 0xd45ec, I get like:
File: ../u-boot.imx.signed
Offset: 0xD45EC
Image Vector Table:
 Offset: 0xD45EC
 IVT Tag: 0xD1
 IVT Version: 0
 IVT Length: 0x20
 HAB Version: 0x41
 Entry: 0x177EDD40
 DCD: 0x0
 Boot Data: 0x0
 Self: 0x177FDD40
 CSF: 0x177FDD60
 Command Sequence File (CSF):
 Offset: 0xD460C
 CSF Tag: 0xD4
 CSF Length: 80 bytes
 HAB Version: 0x41
 Command:
   Command Tag: 0xBE
   Command Length: 12 bytes
   Processing 'Install Key' command...
   Flags: 0x0
   Protocol Tag: 0x3 (SRK certificate format)
   Algorithm Tag: 0x17 (SHA-256 algorithm)
   SRK Table processed
   Source Index: 0
   Target Index: 0
   Certificate Offset: 0x50

[............]

SRK Table Hash: 23969F270F41....
 Key 1:
   Offset: 0xD4E9C
   Length: 1363 bytes
Invalid key length
 Signature 1:
   Offset: 0xD53F0
   Length: 770 bytes
Invalid signature length

For SPL, 0x0 is correct, in the sense that I have a similar output including the invalid key and invalid signature length

Same thing for the kernel fitImage, with offset 0x0 I don't have any IVT table (since it's not present from  yocto) but after signing I can see all the info (including invalid key and signature length) at offset 0x1623000

On another parallel project (which doesn't make use of SPL) we can have a similar output, including the invalid key and invalid signature length using offset =0x0 when checking u-boot.imx

I am currently working with an imx6dl is the "Entry: 0x908000" present in IVT table correct?

Thanks in advance

Best Regards

Renato

[Harvey021]

Hello @imx8mp_developer 

For the u-boot.imx, its structure is IVT+DCD+U-Boot.bin. As our guides the SPL may not needed.

For IVT table, it can be presented in 908000.

Regards

Harvey

[imx8mp_developer]

Hello, thanks for your answer!

Problem is, my SPL.bin and u-boot.imx have the same IVT table

File: u-boot.imx
Offset: 0x0
Image Vector Table:
 Offset: 0x0
 IVT Tag: 0xD1
 IVT Version: 0
 IVT Length: 0x20
 HAB Version: 0x40
 Entry: 0x908000
 DCD: 0x0
 Boot Data: 0x907420
 Self: 0x907400
 CSF: 0x914000
Invalid CSF tag


So I guess that even if I add a signature at the end of the u-boot.imx, the CSF address may be totally wrong