On 6/5/19 3:52 PM, Tom Rini wrote: > 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.
I agree with this. I would still like to have an open alternative available though. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot