Re: IMX8M Mini HAB secure boot - working?

[Tim Harvey <tharvey@gateworks.com>]

On Sun, Jul 18, 2021 at 9:01 PM Heiko Schocher <hs@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@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?

>
> 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.

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
u-boot-nodtb.bin from within the FIT image, the third block is the dtb
from within the FIT, and the fourth block is the ATF from within the
FIT.

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.

Thanks,

Tim