[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> container format file
> 
> On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote:
> > On 6/5/19 5:03 AM, Peng Fan wrote:
> > [...]
> > >>>>> It is not duplication of FIT. Container support the similar
> > >>>>> function of FIT image, but it is not only that.
> > >>>>
> > >>>> So what is it ?
> > >>>
> > >>>
> > >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > >>>
> > >>
> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da
> > >> ta=02%7C
> > >>>
> > >>
> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
> > >> 86ea1d3b
> > >>>
> > >>
> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&sdat
> > >> a=KO%2B0e
> > >>>
> > >>
> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&reserv
> > >> ed=0
> > >>> Chapter 5 has information about container set and container.
> > >>
> > >> Thanks, any specific part of those 80 pages ?
> > >
> > > Figure 5-24. Container Format has a picture about a single container.
> > > i.MX8 container also support container sets, support encrypt blob,
> > > certificates, SRK management. Support signature to the whole
> > > container, no need single image inside container.
> >
> > Isn't that all supported in fitImage too ?
> 
> This is neither the first nor last time functionality has been essentially
> duplicated, sadly, for reasons.

I'll share the fit things to our ROM stakeholders, but they take decision
on new SoC design.

> 
> > >>>> I don't think I get it. Why would I, as an iMX8 user, want to
> > >>>> pick custom new vendor-specific format over years-proven generic
> fitImage?
> > >>>
> > >>> We not against FIT, we already use FIT on i.MX8M, to let spl to
> > >>> authenticate FIT image using ROM HAB, not using crypto driver.
> > >>
> > >> Great
> > >>
> > >>>> What is the selling point here ?
> > >>>
> > >>> We would not introduce cypto driver in SPL stage, that means HAB
> > >>> FIT and AHAB container needs to be dropped when SPL loading other
> images.
> > >>> ROM already provides API for bootloader to authenticate images,
> > >>> introducing complex crypto driver in SPL could enlarge code size
> > >>> and make things complicated.
> > >>
> > >> Ah I see, so it's all making the whole crypto simpler by offloading
> > >> the hard parts into the firmware, which just magically handles
> > >> everything , without having much extra code in the SPL ?
> > >
> > > Yes. Use what ROM provides will make things easier for U-Boot.
> >
> > Is it possible to perform a security audit on the ROM as easily as on
> > U-Boot ? I mean, U-Boot is free software, the source is available, so
> > security researchers can easily scrutinize it. Is the ROM ?
> 
> So, here's my two cents (and it may or may not seem contradictory with my
> opinions in the secure boot thread going on currently on the Linaro Boot
> Architecture list).  Yes, it would and IMHO is better when we use free and
> open software to solve our problems (and an aside to the RISC-V folks as this
> is yet another area they can make the world a better place in).  But I am a
> believe in dealing with the world as it stands at times too.  The question isn't
> "can we get NXP to re-spin i.MX8 to use the FIT image format?" as that's
> obviously going to be "No.".  The question is, "can we support this format in
> a clean manner?" and the answer is obviously "Yes.".  So please lets keep
> that in mind with reviewing the code as at the end of the day it is more
> beneficial for this to be supported in mainline U-Boot than only supported in
> the vendor tree.

Thanks. So I think you agree the current approach. Could I get any A-b or R-b
tags from the list?

Thanks,
Peng.

> Thanks!
> 
> --
> Tom