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

[Marek Vasut]

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