On 6/6/19 4:33 AM, Peng Fan wrote: >> 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?
I would still like an answer to my question about the security auditing above. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot