From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Date: Thu, 6 Jun 2019 07:54:51 +0000 Subject: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file In-Reply-To: <9df27c64-b54e-7c65-56a9-9b0481378ded@denx.de> References: <9faa828b-9ebc-8bc7-9232-6ce1ff8f75a8@denx.de> <479ee7a2-8225-7211-46d6-0f9bd2e95881@denx.de> <20190605135201.GN7705@bill-the-cat> <9df27c64-b54e-7c65-56a9-9b0481378ded@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > 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. Sorry. Missed your thread. I not work on ROM stuff, but I think answer is no to public. Thanks, Peng. > > -- > Best regards, > Marek Vasut