HAB auth failure on eMMC

[allenivester]

I'm trying to enable secure boot (no encryption at this point) for a custom i.MX6 DL board using single-stage u-boot (no SPL).  For development purposes, I started off getting secure boot working from USB using mfgtool2.  This (I thought) was the harder case, since it requires an additional signing of just the DCD.  I have that working perfectly and even extended u-boot to HAB authenticate a next-stage image loaded in u-boot.  Once all of that was working, I tried the "simple" case of signing the exact same u-boot.imx image for booting from emmc.  But although u-boot does load from emmc, when I run hab_status I get a HAB_INV_ADDRESS failure and the expected subsequent HAB_INV_ASSERTION failures for the various required signed section.  Again, I'm using the exact same u-boot.imx image for both mfgtool loading and emmc, with the only difference in signing being the mfgtool CSF script adds an auth_data block for the DCD at 0x00910000.

Everything about the failing emmc-loaded image looks good.  I've even read the binary back from the emmc boot block and verified the addresses in the IVT, which is exactly the same as the IVT for the mfgtool-loaded image that generates no HAB errors.  The only weird thing I see with the failing emmc-loaded u-boot is shown below.

First, see the IVT header of the image and note that the CSF starts at 0x17860000

=> md 177ff400
177ff400: 402000d1 17800000 00000000 177ff42c .. @........,...
177ff410: 177ff420 177ff400 17860000 00000000 ...............
177ff420: 177ff000 0006100c 00000000 403802d2 ..............8@
177ff430: 043402cc 74070e02 00000c00 54070e02 ..4....t.......T
177ff440: 00000000 ac040e02 30000000 b0040e02 ...........0....
177ff450: 30000000 64040e02 30000000 90040e02 ...0...d...0....
177ff460: 30000000 4c070e02 30000000 94040e02 ...0...L...0....
177ff470: 30000000 a0040e02 00000000 b4040e02 ...0............
177ff480: 30000000 b8040e02 30000000 6c070e02 ...0.......0...l
177ff490: 30000000 50070e02 00000200 bc040e02 ...0...P........
177ff4a0: 30000000 c0040e02 30000000 c4040e02 ...0.......0....
177ff4b0: 30000000 c8040e02 30000000 60070e02 ...0.......0...`
177ff4c0: 00000200 64070e02 30000000 70070e02 .......d...0...p
177ff4d0: 30000000 78070e02 30000000 7c070e02 ...0...x...0...|
177ff4e0: 30000000 70040e02 30000000 74040e02 ...0...p...0...t
177ff4f0: 30000000 78040e02 30000000 7c040e02 ...0...x...0...|

Now, let's dump the CSF and make sure it's correct.

=> md 17860000
17860000: 415000d4 000c00be 00001703 50000000 ..PA...........P
17860010: 020c00be 01000009 90080000 000c00ca ................
17860020: 001dc501 e40d0000 000c00be 02000009 ................
17860030: e8100000 001400ca 001dc502 3c160000 ...............<
17860040: 00f47f17 000c0600 1d0800b2 02000000 ................
17860050: 404008d7 210f02e1 80000000 03000002 ..@@...!........
17860060: 39cd06c9 33493af4 56654fe7 49bde4ab ...9.:I3.OeV...I
17860070: c2a1d13f c4ce48f5 55b42b7c e97c58fe ?....H..|+.U.X|.
17860080: 4856e396 e6420643 f25c8c1c 659e382f ..VHC.B...\./8.e
17860090: 70964933 c31fa267 190d1a11 23082f65 3I.pg.......e/.#
178600a0: fe81449c cc6bf06d 1a8e765f fd85da8e .D..m.k._v......
178600b0: 7be1c9bf 66b2bda4 ff82e68e 8257ce59 ...{...f....Y.W.
178600c0: 5c038885 497772e6 de36eeb4 ee1c70c0 ...\.rwI..6..p..
178600d0: 253367ff 4c1d3dfe 65851ba1 aa4e7d76 .g3%.=.L...ev}N.
178600e0: 3b0099bb 1a86b6cf 3765c5fc d2e12b3e ...;......e7>+..
178600f0: 910fb1ac 12115d8c 35a5eb93 d037fb86 .....].....5..7.
=>
17860100: 8a44f895 7ec56905 e64d49ed 4b0adf68 ..D..i.~.IM.h..K
17860110: 56a0b1dc f4b3f1e2 3acb9b29 b9690a83 ...V....)..:..i.
17860120: 9d9ccff1 e658b6aa ae674de2 a47aee14 ......X..Mg...z.
17860130: 1e40bd78 0557d7f8 5f2905ba f75f303c x.@...W...)_<0_.
17860140: 423b7325 524a4bb2 be96254d 6a702d4c %s;B.KJRM%..L-pj
17860150: f1410a9c cf160b7e ddea8d8d 18448395 ..A.~.........D.
17860160: 773466d5 53780d7c 78a6c720 ce78b75a .f4w|.xS ..xZ.x.
17860170: 985f9344 a618a85b 122eeb34 8f798e7c D._.[...4...|.y.
17860180: 97b723d6 32786a78 867d0121 30e366ed .#..xjx2!.}..f.0
17860190: 0597f1cb a30d7943 471dc9ab 29af42ff ....Cy.....G.B.)
178601a0: 03716679 f71aa23c b58db623 a4f1f3a0 yfq.<...#.......
178601b0: c9cad24b 9ac9e300 8375e47c 37366de9 K.......|.u..m67
178601c0: 97d17825 d4d924c2 3f9ab852 b82a5d96 %x...$..R..?.]*.
178601d0: 3b196d2a a289ae9d e28227a8 1a579aff *m.;.....'....W.
178601e0: bd0ce3a4 5c95043e 4e3a11c1 71ee7f77 ....>..\..:Nw..q
178601f0: 3cfdccf9 d95932b5 f6e35746 2a9fcbb5 ...<.2Y.FW.....*
=>
17860200: 00000000 00000000 00000000 00000000 ................
17860210: 00000000 00000000 00000000 00000000 ................
17860220: 00000000 00000000 00000000 00000000 ................
17860230: 00000000 00000000 00000000 00000000 ................
17860240: 00000000 00000000 00000000 00000000 ................
17860250: 00000000 00000000 00000000 00000000 ................
17860260: 00000000 00000000 00000000 00000000 ................
17860270: 00000000 00000000 00000000 00000000 ................
17860280: 00000000 00000000 00000000 00000000 ................
17860290: 00000000 00000000 00000000 00000000 ................
178602a0: 00000000 00000000 00000000 00000000 ................
178602b0: 00000000 00000000 00000000 00000000 ................
178602c0: 00000000 00000000 00000000 00000000 ................
178602d0: 00000000 00000000 00000000 00000000 ................
178602e0: 00000000 00000000 00000000 00000000 ................
178602f0: 00000000 00000000 00000000 00000000 ................

As you see, after 512 bytes, the CSF (in memory) is zeroes.  When I read the contents of the boot block from emmc, I see the full CSF, which matches the signed image on my PC.  So for some reason the i.MX6 boot ROM isn't reading the entire image from emmc.

Why?  I assume the CSF has a header that lets the ROM figure out how much to copy when it's loading the image, but although some fields in the first 0x60 bytes of the CSF look like lengths, nothing looks obvious.  So how is the boot ROM not loading the whole u-boot image + CSF into RAM?  Could there be something wrong in the emmc setup in the DCD?  Or am I barking up the wrong tree?

Thanks.

[allenivester · Accepted solution]

I figured out the problem myself.

The problem is with the boot_data length.  I'm based on a u-boot commit from 2017.01 (yeah, I know, not a tag) and mkimage -T imximage generates the boot_data field, and it's specifying the length as 0x6100c, when in fact that's not big enough to cover the appended CSF.  I'll need to look into how boot_data is generated, but for testing purposes I just hand-modified the length to be 0x62c00 (0x60c00 for u-boot.imx length + 0x2000 for padded CSF binary).  And voila, the full CSF is copied from emmc and no HAB errors are reported.

I think the reason loading from mfgtools worked is because mfgtools loads the file directly to RAM via USB based on the file size rather than parsing the IVT.

[b36401]

Thanx for letting us know that everything is fine now.
And just in case here is a document regarding to HAB:

https://community.nxp.com/docs/DOC-105193

Have a great day,
Victor

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[allenivester]

BTW, I parsed the CSF using the values from the HAB API doc (in cst), and it looks fine.  There is only one absolute address in the CSF header and it's the correct load addr (0x177ff400).  And the CSF offset that follows in the header is correct (0x60c00).  And all of the structures and commands (and their lengths) that follow are correct and can be traced all the way to the end of the CSF.  So I don't think HAB is failing due to anything incorrect in the CSF.

I'd suspect the DCD settings except that the mx6 loads and executes u-boot from emmc with no problem ... it's only the CSF that is truncated to 512 bytes (probably a single sector size in the ROM loader).  I would think any ddr or mmc init problems would affect the entire u-boot image, not just the CSF.  I've also tried booting from SD card and I get the same result -- truncated CSF.

Oh, and I did also verify that when I load the exact same image using mfgtools, the CSF is not truncated.  The image isn't signed for mfgtools (since it's intended to boot from emmc), so I obviously get a HAB signature error, but the point is the CSF is intact.

And that's interesting.  Why am I getting a HAB_INV_ADDRESS error, when the exact same image (loaded to the same RAM location) using mfgtools only gives me a signature error, which occurs later in the HAB auth process?  I'm suspicious of the DCD again .... specifically, mmc init (since that is unique to emmc / sd booting).