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?
Thanks, Peng.
Thanks!
-- Tom