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

Marek Vasut marex at denx.de
Wed Jun 5 13:55:14 UTC 2019


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


More information about the U-Boot mailing list