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

[Tom Rini <trini@konsulko.com>]

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190605/8c85ad54/attachment.sig>