IMX8M Mini HAB secure boot - working?

[Heiko Schocher]

Hello Tim,

On 20.07.21 00:23, Tim Harvey wrote:
> On Sun, Jul 18, 2021 at 9:01 PM Heiko Schocher <hs at denx.de> wrote:
>>
>> Hello Tim,
>>
>> On 12.07.21 18:06, Tim Harvey wrote:
>>> On Sat, Jul 10, 2021 at 5:24 AM Heiko Schocher <hs at denx.de> wrote:
>>>>
>>>> Hi Tim, Stefano,
>>>>
>>>> On 10.07.21 11:14, Stefano Babic wrote:
>>>>> Hi Tim,
>>>>>
>>>>> On 10.07.21 02:05, Tim Harvey wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> Has anyone successfully used secure boot with IMX8M Mini or other
>>>>>> IMX8M? Peng's recent series got merged with the exception of what
>>>>>> looks like the addition of couple of 'caam' commands to blob/deblob
>>>>>> DEK's.
>>>>>>
>>>>>> There are no guides yet however I'm following the guides for the
>>>>>> downstream NXP U-Boot and thus far have been able to get the SPL to
>>>>>> boot with no HAB events but when it tries to authenticate the FIT
>>>>>> image it validate_ivt fails with 'Error: Invalid IVT structure'.
>>>>>
>>>>> Heiko tested this and found it, if I am not wrong he found the cause. Added him in CC.
>>>>>
>>>>> I have also planned to test this, it is on my TODO list...
>>>>
>>>> I am currently not in my office, the whole next week ... so I could not
>>>> check my current state of the patches... but I found a problem, yes.
>>>>
>>>> The problem was that the ROM API loaded the IVT header to a
>>>> memallocated address, which does of course not fit with the
>>>> address you have in IVT header ...
>>>>
>>>> I have not full access to my development setup ,and found on my local
>>>> some old state of the patches .... may you can try them?
>>>>
>>>> Of course they need a rework, other solution, but it shows the problem
>>>> hopefully...
>>>>
>>>
>>> Heiko,
>>>
>>> Thank you - that was indeed the issue and your patches resolve it. I
>>
>> Cool! Thanks for testing!
>>
>>> have not seen your patch posted to the list and your commit msg makes
>>
>> Yes, as they are WIP not posted yet ... and I thought, I make something
>> wrong ... but if you have the same problem, it seems it is a real bug!
>>
>>> it seem like your not sure if you should make it SoC dependent. Do you
>>> plan on submitting these to the mailing list?
>>
>> The question is: is my approach to fix it the way to go? If you think so,
>> I can send them .. but give me please some time as I am just back from
>> vacation...
>>
>> Fast look into it:
>>
>> spl_load_simple_fit_fix_load() must also check if there is at "fit"
>> pointer an IVT header, if not, return simply fit pointer.
> 
> Yes, otherwise non-hab will fail, correct?

Yes.

>> Question: dependent on SoC ... as it is in common code, and I think we
>>   need this "fix" only for imx8m?, so yes, it should be SoC dependent
>>   or better only imx8m? code defines this function... if possible.
>>   Therefore the weak function approach.
>>
>> If you find time for looking at it, I am fine, if you use my patches
>> as base and you can post them?
>>
> 
> I may be able to look at it again later this week or next.

Fine.

> I did run into another snag in that I could not figure out a proper
> CSF template for multiple DTB's. When I try to include mulitple DTB's
> I get several HAB events.
> 
> flash.log:
> ...
> ========= OFFSET dump =========
> Loader IMAGE:
>  header_image_off       0x0
>  image_off              0x40
>  csf_off                0x33200
>  spl hab block:         0x7e0fc0 0x0 0x33200
> 
> Second Loader IMAGE:
>  sld_header_off         0x57c00
>  sld_csf_off            0x58c20
>  sld hab block:         0x401fcdc0 0x57c00 0x1020
> 
> csf_fit.txt:
> ...
> [Authenticate Data]
>     # Key slot index used to authenticate the image data
>     Verification index = 2
>     # Authenticate Start Address, Offset, Length and file
>     Blocks = \
>         0x401fcdc0 0x00057c00 0x00001020 "flash.bin", \
>         0x40200000 0x0005ac00 0x000b0150 "flash.bin", \
>         0x402b0150 0x0010ad50 0x00008bc4 "flash.bin", \
>         0x00920000 0x00113914 0x00009159 "flash.bin"
> 
> So that first block is the FIT image header I think (only 4128 bytes
> long) using data from flash.log 'sld hab block:', the second block is

Yes

> u-boot-nodtb.bin from within the FIT image, the third block is the dtb

Yes and yes

> from within the FIT, and the fourth block is the ATF from within the
> FIT.

Yes

> When I have multiple DTB's do I need a block per DTB? I haven't found
> any example of a CSF template where CONFIG_OF_LIST has multiple dtb's.

Hmm... good question... I think (not tested) when you have multiple
DTBs the DTBs are packed into a FIT image, so you have again only one
"dtb" part to sign...

./doc/README.multi-dtb-fit says:
"""
The relevant DTBs are packed into a FIT (list provided by CONFIG_OF_LIST). The
FIT is automatically generated at the end of the compilation and appended to
u-boot.bin so that U-Boot can locate it and select the correct DTB from inside
the FIT.
"""

So I think no problem...or?

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de