Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 6/6/19 9:54 AM, Peng Fan wrote: [...] 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. I see. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> 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.pdfda > > ta=02%7C > >> > > > >> > 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 > > 86ea1d3b > >> > > > >> > c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat > > a=KO%2B0e > >> > > > >> > E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv > > 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [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.pdfda > ta=02%7C >> > >> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 > 86ea1d3b >> > >> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat > a=KO%2B0e >> > >> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv > 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
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > On Thu, 6 Jun 2019 02:33:14 + > 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.pdfda > > > > >> ta=02%7C > > > > >>> > > > > >> > > > > 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 > > > > >> 86ea1d3b > > > > >>> > > > > >> > > > > c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat > > > > >> a=KO%2B0e > > > > >>> > > > > >> > > > > E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv > > > > >> 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? > > Just to add my 2 cents... > > Please if possible provide a good (and as much verbose as possible) entry > to ./doc/README.imx_image (or something) regarding the i.MX8 format. ok. I'll post out a separate patch for that. Regards, Peng. > > Thanks in advance, > > > > > Thanks, > > Peng. > > > > > Thanks! > > > > > > -- > > > Tom > > > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: > lu...@denx.de ___ U-Boot mailing list
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On Thu, 6 Jun 2019 02:33:14 + 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.pdfda > > > >> ta=02%7C > > > >>> > > > >> > > 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 > > > >> 86ea1d3b > > > >>> > > > >> > > c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat > > > >> a=KO%2B0e > > > >>> > > > >> > > E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv > > > >> 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? Just to add my 2 cents... Please if possible provide a good (and as much verbose as possible) entry to ./doc/README.imx_image (or something) regarding the i.MX8 format. Thanks in advance, > > Thanks, > Peng. > > > Thanks! > > > > -- > > Tom Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpweJyQXgFss.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> 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.pdfda > > >> ta=02%7C > > >>> > > >> > 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 > > >> 86ea1d3b > > >>> > > >> > c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat > > >> a=KO%2B0e > > >>> > > >> > E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv > > >> 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
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.pdfda ta=02%7C > 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 86ea1d3b > c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat a=KO%2B0e > E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [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.pdfda > >> ta=02%7C > >>> > >> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 > >> 86ea1d3b > >>> > >> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat > >> a=KO%2B0e > >>> > >> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv > >> 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. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
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.pdfda >> ta=02%7C >>> >> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 >> 86ea1d3b >>> >> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat >> a=KO%2B0e >>> >> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv >> 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 ? >> 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 ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > On 6/5/19 3:59 AM, Peng Fan wrote: > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading > >> i.MX container format file > >> > >> On 6/5/19 3:18 AM, Peng Fan wrote: > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > loading i.MX container format file > > On 6/4/19 5:27 AM, Peng Fan wrote: > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > >> loading i.MX container format file > >> > >> On 5/30/19 9:06 AM, Ye Li wrote: > >>> On 2019/5/27 19:31, Marek Vasut wrote: > Caution: EXT Email > > On 5/27/19 11:49 AM, Peng Fan wrote: > > Hi Marek, Lukasz, > > > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > >> loading i.MX container format file > >> > >> Hi Marek, > >> > >> On 2019/5/22 19:41, Marek Vasut wrote: > >>> Caution: EXT Email > >>> > >>> On 5/22/19 9:34 AM, Lukasz Majewski wrote: > >>> [...] > >> By using above approach we do have the NXP's > >> "container" > >> format only seen in the SPL (which is OK, as for > >> example Samsung does similar thing with FBL/BL1). > >> When > >> SPL is > >> "trused" > >> we may use available facilities. > > > > The issue to me is that sc_seco_authenticate could not > > take a FIT image as input. > > Is the sc_seco_authenticate an API accessible from SPL, > U-Boot proper or Linux crypro engine driver? > >>> > >>> Yes, it is an API accessible in SPL/U-Boot stage. I do > >>> not know about Linux crypto driver. > >> > >> Maybe it would be worth to check how Linux handle this? > >> Maybe it would shed some more light on it? > > > > I am not familiar with that, so might be stupid question > below. > > Does it really matter? > > I would check it just out of curiosity. > >>> > >>> Yes, it matters, because there should be such API. How would > >>> Linux authenticate e.g. userspace binaries if there wasn't > >>> one, surely not by wrapping every single object into the > >>> custom vendor-specific > >> container ? > >>> And if there is one, you can use it to authenticate raw > >>> binaries from U-Boot SPL too, e.g. fitImage blobs with an > >>> associated > signature. > >>> > >> > >> iMX8 AHAB uses RSA key pair for authentication, the on-chip > >> thing we called SRK is a array of public key hash which is > >> dedicated for AHAB. It is not a real key. The real public key > >> is in > >> container. > >> AHAB will check the public key with the on-chip SRK before > >> using it to authenticate the image. > >> Seco which contains the crypto engine on imx8 does not allow > >> to use the SRK by user. No such API exported. > >> And the fuse of SRK is locked, can't be read directly. > >> > >> Actually on imx6/imx7/imx8m, the SPL and u-boot are already > >> using ROM HAB to implement the trust chain, like SPL > >> authenticates u-boot, u-boot authenticatse kernel. We just > >> follow this same way on imx8, the difference is > >> imx8 needs container format for signed image. We prefer > >> directly loading container image than fit image. > >> If we pack fit image into container, obviously this will > >> cause one more > >> copy. > >> As a boot loader, isn't it better to have more image format > >> supported? > > If the functionality of the new image format is a subset of > already present image format, then no, that's called a duplication. > > >> We > >> don't force to use container, just set it as default. Users > >> still can choose fit or raw image. > > They can. however they cannot authenticate the fitImage because > the firmware doesn't provide the necessary API for that ? > > > > > Do you have more comment? > > How could Linux use this iMX8 chain of trust stuff to authenticate > e.g. > userspace binaries ? It's the same thing as authenticating blob > in a fitImage. > > >>> > >>> Userspace binaries don't use the same key pair. They are signed > >>> by software vendors' key. The private key for chip secure boot > >>> is only hold by > >> device manufacturer. > >>> For example, android needs to authenticate a signed APK. Its
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 6/5/19 3:59 AM, Peng Fan wrote: >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX >> container format file >> >> On 6/5/19 3:18 AM, Peng Fan wrote: Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file On 6/4/19 5:27 AM, Peng Fan wrote: >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support >> loading i.MX container format file >> >> On 5/30/19 9:06 AM, Ye Li wrote: >>> On 2019/5/27 19:31, Marek Vasut wrote: Caution: EXT Email On 5/27/19 11:49 AM, Peng Fan wrote: > Hi Marek, Lukasz, > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support >> loading i.MX container format file >> >> Hi Marek, >> >> On 2019/5/22 19:41, Marek Vasut wrote: >>> Caution: EXT Email >>> >>> On 5/22/19 9:34 AM, Lukasz Majewski wrote: >>> [...] >> By using above approach we do have the NXP's >> "container" >> format only seen in the SPL (which is OK, as for >> example Samsung does similar thing with FBL/BL1). >> When >> SPL is >> "trused" >> we may use available facilities. > > The issue to me is that sc_seco_authenticate could not > take a FIT image as input. Is the sc_seco_authenticate an API accessible from SPL, U-Boot proper or Linux crypro engine driver? >>> >>> Yes, it is an API accessible in SPL/U-Boot stage. I do not >>> know about Linux crypto driver. >> >> Maybe it would be worth to check how Linux handle this? >> Maybe it would shed some more light on it? > > I am not familiar with that, so might be stupid question below. > Does it really matter? I would check it just out of curiosity. >>> >>> Yes, it matters, because there should be such API. How would >>> Linux authenticate e.g. userspace binaries if there wasn't >>> one, surely not by wrapping every single object into the >>> custom vendor-specific >> container ? >>> And if there is one, you can use it to authenticate raw >>> binaries from U-Boot SPL too, e.g. fitImage blobs with an >>> associated signature. >>> >> >> iMX8 AHAB uses RSA key pair for authentication, the on-chip >> thing we called SRK is a array of public key hash which is >> dedicated for AHAB. It is not a real key. The real public key is in >> container. >> AHAB will check the public key with the on-chip SRK before >> using it to authenticate the image. >> Seco which contains the crypto engine on imx8 does not allow to >> use the SRK by user. No such API exported. >> And the fuse of SRK is locked, can't be read directly. >> >> Actually on imx6/imx7/imx8m, the SPL and u-boot are already >> using ROM HAB to implement the trust chain, like SPL >> authenticates u-boot, u-boot authenticatse kernel. We just >> follow this same way on imx8, the difference is >> imx8 needs container format for signed image. We prefer >> directly loading container image than fit image. >> If we pack fit image into container, obviously this will cause >> one more >> copy. >> As a boot loader, isn't it better to have more image format >> supported? If the functionality of the new image format is a subset of already present image format, then no, that's called a duplication. >> We >> don't force to use container, just set it as default. Users >> still can choose fit or raw image. They can. however they cannot authenticate the fitImage because the firmware doesn't provide the necessary API for that ? > > Do you have more comment? How could Linux use this iMX8 chain of trust stuff to authenticate e.g. userspace binaries ? It's the same thing as authenticating blob in a fitImage. >>> >>> Userspace binaries don't use the same key pair. They are signed by >>> software vendors' key. The private key for chip secure boot is >>> only hold by >> device manufacturer. >>> For example, android needs to authenticate a signed APK. Its >>> public key (Key >> A) is in system FS. >>> iMX trust chain only reaches to kernel + ramdisk. Then the chain >>> hands over >> to android. >>> In ramdisk, android puts another public Key (Key B) used by >>> dm-verify for system FS. So once system FS is verified ok, then >>> the public key A becomes trusted.
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > On 6/5/19 3:18 AM, Peng Fan wrote: > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading > >> i.MX container format file > >> > >> On 6/4/19 5:27 AM, Peng Fan wrote: > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > loading i.MX container format file > > On 5/30/19 9:06 AM, Ye Li wrote: > > On 2019/5/27 19:31, Marek Vasut wrote: > >> Caution: EXT Email > >> > >> On 5/27/19 11:49 AM, Peng Fan wrote: > >>> Hi Marek, Lukasz, > >>> > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > loading i.MX container format file > > Hi Marek, > > On 2019/5/22 19:41, Marek Vasut wrote: > > Caution: EXT Email > > > > On 5/22/19 9:34 AM, Lukasz Majewski wrote: > > [...] > By using above approach we do have the NXP's > "container" > format only seen in the SPL (which is OK, as for > example Samsung does similar thing with FBL/BL1). > When > SPL is > "trused" > we may use available facilities. > >>> > >>> The issue to me is that sc_seco_authenticate could not > >>> take a FIT image as input. > >> > >> Is the sc_seco_authenticate an API accessible from SPL, > >> U-Boot proper or Linux crypro engine driver? > > > > Yes, it is an API accessible in SPL/U-Boot stage. I do not > > know about Linux crypto driver. > > Maybe it would be worth to check how Linux handle this? > Maybe it would shed some more light on it? > >>> > >>> I am not familiar with that, so might be stupid question below. > >>> Does it really matter? > >> > >> I would check it just out of curiosity. > > > > Yes, it matters, because there should be such API. How would > > Linux authenticate e.g. userspace binaries if there wasn't > > one, surely not by wrapping every single object into the > > custom vendor-specific > container ? > > And if there is one, you can use it to authenticate raw > > binaries from U-Boot SPL too, e.g. fitImage blobs with an > > associated > >> signature. > > > > iMX8 AHAB uses RSA key pair for authentication, the on-chip > thing we called SRK is a array of public key hash which is > dedicated for AHAB. It is not a real key. The real public key is in > container. > AHAB will check the public key with the on-chip SRK before > using it to authenticate the image. > Seco which contains the crypto engine on imx8 does not allow to > use the SRK by user. No such API exported. > And the fuse of SRK is locked, can't be read directly. > > Actually on imx6/imx7/imx8m, the SPL and u-boot are already > using ROM HAB to implement the trust chain, like SPL > authenticates u-boot, u-boot authenticatse kernel. We just > follow this same way on imx8, the difference is > imx8 needs container format for signed image. We prefer > directly loading container image than fit image. > If we pack fit image into container, obviously this will cause > one more > copy. > As a boot loader, isn't it better to have more image format > supported? > >> > >> If the functionality of the new image format is a subset of > >> already present image format, then no, that's called a duplication. > >> > We > don't force to use container, just set it as default. Users > still can choose fit or raw image. > >> > >> They can. however they cannot authenticate the fitImage because > >> the firmware doesn't provide the necessary API for that ? > >> > >>> > >>> Do you have more comment? > >> > >> How could Linux use this iMX8 chain of trust stuff to authenticate e.g. > >> userspace binaries ? It's the same thing as authenticating blob > >> in a fitImage. > >> > > > > Userspace binaries don't use the same key pair. They are signed by > > software vendors' key. The private key for chip secure boot is > > only hold by > device manufacturer. > > For example, android needs to authenticate a signed APK. Its > > public key (Key > A) is in system FS. > > iMX trust chain only reaches to kernel + ramdisk. Then the chain > > hands over > to android. > > In ramdisk, android puts another public Key (Key B) used by > > dm-verify for system FS. So once system FS is verified ok, then > > the public key A becomes trusted. Finally we can use public key A > >
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 6/5/19 3:18 AM, Peng Fan wrote: >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX >> container format file >> >> On 6/4/19 5:27 AM, Peng Fan wrote: Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file On 5/30/19 9:06 AM, Ye Li wrote: > On 2019/5/27 19:31, Marek Vasut wrote: >> Caution: EXT Email >> >> On 5/27/19 11:49 AM, Peng Fan wrote: >>> Hi Marek, Lukasz, >>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file Hi Marek, On 2019/5/22 19:41, Marek Vasut wrote: > Caution: EXT Email > > On 5/22/19 9:34 AM, Lukasz Majewski wrote: > [...] By using above approach we do have the NXP's "container" format only seen in the SPL (which is OK, as for example Samsung does similar thing with FBL/BL1). When SPL is "trused" we may use available facilities. >>> >>> The issue to me is that sc_seco_authenticate could not >>> take a FIT image as input. >> >> Is the sc_seco_authenticate an API accessible from SPL, >> U-Boot proper or Linux crypro engine driver? > > Yes, it is an API accessible in SPL/U-Boot stage. I do not > know about Linux crypto driver. Maybe it would be worth to check how Linux handle this? Maybe it would shed some more light on it? >>> >>> I am not familiar with that, so might be stupid question below. >>> Does it really matter? >> >> I would check it just out of curiosity. > > Yes, it matters, because there should be such API. How would > Linux authenticate e.g. userspace binaries if there wasn't one, > surely not by wrapping every single object into the custom > vendor-specific container ? > And if there is one, you can use it to authenticate raw binaries > from U-Boot SPL too, e.g. fitImage blobs with an associated >> signature. > iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called SRK is a array of public key hash which is dedicated for AHAB. It is not a real key. The real public key is in container. AHAB will check the public key with the on-chip SRK before using it to authenticate the image. Seco which contains the crypto engine on imx8 does not allow to use the SRK by user. No such API exported. And the fuse of SRK is locked, can't be read directly. Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM HAB to implement the trust chain, like SPL authenticates u-boot, u-boot authenticatse kernel. We just follow this same way on imx8, the difference is imx8 needs container format for signed image. We prefer directly loading container image than fit image. If we pack fit image into container, obviously this will cause one more copy. As a boot loader, isn't it better to have more image format supported? >> >> If the functionality of the new image format is a subset of already >> present image format, then no, that's called a duplication. >> We don't force to use container, just set it as default. Users still can choose fit or raw image. >> >> They can. however they cannot authenticate the fitImage because the >> firmware doesn't provide the necessary API for that ? >> >>> >>> Do you have more comment? >> >> How could Linux use this iMX8 chain of trust stuff to authenticate e.g. >> userspace binaries ? It's the same thing as authenticating blob in >> a fitImage. >> > > Userspace binaries don't use the same key pair. They are signed by > software vendors' key. The private key for chip secure boot is only > hold by device manufacturer. > For example, android needs to authenticate a signed APK. Its public > key (Key A) is in system FS. > iMX trust chain only reaches to kernel + ramdisk. Then the chain > hands over to android. > In ramdisk, android puts another public Key (Key B) used by > dm-verify for system FS. So once system FS is verified ok, then the > public key A becomes trusted. Finally we can use public key A for APK >> authentication. So can we put a public key into the SPL and use it to verify a fitImage ? >>> >>> Technically doable. But compared with the current approach that reuse >>> ROM public API, Using crypto driver in SPL will be complicated and >>> code size larger without calling ROM API. >>> >>> I do not understand the problem the SPL loading NXP
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > On 6/4/19 5:27 AM, Peng Fan wrote: > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading > >> i.MX container format file > >> > >> On 5/30/19 9:06 AM, Ye Li wrote: > >>> On 2019/5/27 19:31, Marek Vasut wrote: > Caution: EXT Email > > On 5/27/19 11:49 AM, Peng Fan wrote: > > Hi Marek, Lukasz, > > > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > >> loading i.MX container format file > >> > >> Hi Marek, > >> > >> On 2019/5/22 19:41, Marek Vasut wrote: > >>> Caution: EXT Email > >>> > >>> On 5/22/19 9:34 AM, Lukasz Majewski wrote: > >>> [...] > >> By using above approach we do have the NXP's "container" > >> format only seen in the SPL (which is OK, as for example > >> Samsung does similar thing with FBL/BL1). When SPL is > >> "trused" > >> we may use available facilities. > > > > The issue to me is that sc_seco_authenticate could not > > take a FIT image as input. > > Is the sc_seco_authenticate an API accessible from SPL, > U-Boot proper or Linux crypro engine driver? > >>> > >>> Yes, it is an API accessible in SPL/U-Boot stage. I do not > >>> know about Linux crypto driver. > >> > >> Maybe it would be worth to check how Linux handle this? Maybe > >> it would shed some more light on it? > > > > I am not familiar with that, so might be stupid question below. > > Does it really matter? > > I would check it just out of curiosity. > >>> > >>> Yes, it matters, because there should be such API. How would > >>> Linux authenticate e.g. userspace binaries if there wasn't one, > >>> surely not by wrapping every single object into the custom > >>> vendor-specific > >> container ? > >>> And if there is one, you can use it to authenticate raw binaries > >>> from U-Boot SPL too, e.g. fitImage blobs with an associated > signature. > >>> > >> > >> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing > >> we called SRK is a array of public key hash which is dedicated > >> for AHAB. It is not a real key. The real public key is in container. > >> AHAB will check the public key with the on-chip SRK before using > >> it to authenticate the image. > >> Seco which contains the crypto engine on imx8 does not allow to > >> use the SRK by user. No such API exported. > >> And the fuse of SRK is locked, can't be read directly. > >> > >> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using > >> ROM HAB to implement the trust chain, like SPL authenticates > >> u-boot, u-boot authenticatse kernel. We just follow this same way > >> on imx8, the difference is > >> imx8 needs container format for signed image. We prefer directly > >> loading container image than fit image. > >> If we pack fit image into container, obviously this will cause > >> one more > >> copy. > >> As a boot loader, isn't it better to have more image format supported? > > If the functionality of the new image format is a subset of already > present image format, then no, that's called a duplication. > > >> We > >> don't force to use container, just set it as default. Users still > >> can choose fit or raw image. > > They can. however they cannot authenticate the fitImage because the > firmware doesn't provide the necessary API for that ? > > > > > Do you have more comment? > > How could Linux use this iMX8 chain of trust stuff to authenticate e.g. > userspace binaries ? It's the same thing as authenticating blob in > a fitImage. > > >>> > >>> Userspace binaries don't use the same key pair. They are signed by > >>> software vendors' key. The private key for chip secure boot is only > >>> hold by > >> device manufacturer. > >>> For example, android needs to authenticate a signed APK. Its public > >>> key (Key > >> A) is in system FS. > >>> iMX trust chain only reaches to kernel + ramdisk. Then the chain > >>> hands over > >> to android. > >>> In ramdisk, android puts another public Key (Key B) used by > >>> dm-verify for system FS. So once system FS is verified ok, then the > >>> public key A becomes trusted. Finally we can use public key A for APK > authentication. > >> > >> So can we put a public key into the SPL and use it to verify a fitImage ? > > > > Technically doable. But compared with the current approach that reuse > > ROM public API, Using crypto driver in SPL will be complicated and > > code size larger without calling ROM API. > > > > I do not understand the problem the SPL loading NXP i.MX8 container > format. > > SPL should
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 6/4/19 5:27 AM, Peng Fan wrote: >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX >> container format file >> >> On 5/30/19 9:06 AM, Ye Li wrote: >>> On 2019/5/27 19:31, Marek Vasut wrote: Caution: EXT Email On 5/27/19 11:49 AM, Peng Fan wrote: > Hi Marek, Lukasz, > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support >> loading i.MX container format file >> >> Hi Marek, >> >> On 2019/5/22 19:41, Marek Vasut wrote: >>> Caution: EXT Email >>> >>> On 5/22/19 9:34 AM, Lukasz Majewski wrote: >>> [...] >> By using above approach we do have the NXP's "container" >> format only seen in the SPL (which is OK, as for example >> Samsung does similar thing with FBL/BL1). When SPL is >> "trused" >> we may use available facilities. > > The issue to me is that sc_seco_authenticate could not take > a FIT image as input. Is the sc_seco_authenticate an API accessible from SPL, U-Boot proper or Linux crypro engine driver? >>> >>> Yes, it is an API accessible in SPL/U-Boot stage. I do not >>> know about Linux crypto driver. >> >> Maybe it would be worth to check how Linux handle this? Maybe >> it would shed some more light on it? > > I am not familiar with that, so might be stupid question below. > Does it really matter? I would check it just out of curiosity. >>> >>> Yes, it matters, because there should be such API. How would Linux >>> authenticate e.g. userspace binaries if there wasn't one, surely >>> not by wrapping every single object into the custom vendor-specific >> container ? >>> And if there is one, you can use it to authenticate raw binaries >>> from U-Boot SPL too, e.g. fitImage blobs with an associated signature. >>> >> >> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing >> we called SRK is a array of public key hash which is dedicated for >> AHAB. It is not a real key. The real public key is in container. >> AHAB will check the public key with the on-chip SRK before using it >> to authenticate the image. >> Seco which contains the crypto engine on imx8 does not allow to use >> the SRK by user. No such API exported. >> And the fuse of SRK is locked, can't be read directly. >> >> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using >> ROM HAB to implement the trust chain, like SPL authenticates >> u-boot, u-boot authenticatse kernel. We just follow this same way >> on imx8, the difference is >> imx8 needs container format for signed image. We prefer directly >> loading container image than fit image. >> If we pack fit image into container, obviously this will cause one more >> copy. >> As a boot loader, isn't it better to have more image format supported? If the functionality of the new image format is a subset of already present image format, then no, that's called a duplication. >> We >> don't force to use container, just set it as default. Users still >> can choose fit or raw image. They can. however they cannot authenticate the fitImage because the firmware doesn't provide the necessary API for that ? > > Do you have more comment? How could Linux use this iMX8 chain of trust stuff to authenticate e.g. userspace binaries ? It's the same thing as authenticating blob in a fitImage. >>> >>> Userspace binaries don't use the same key pair. They are signed by >>> software vendors' key. The private key for chip secure boot is only hold by >> device manufacturer. >>> For example, android needs to authenticate a signed APK. Its public key (Key >> A) is in system FS. >>> iMX trust chain only reaches to kernel + ramdisk. Then the chain hands over >> to android. >>> In ramdisk, android puts another public Key (Key B) used by dm-verify >>> for system FS. So once system FS is verified ok, then the public key A >>> becomes trusted. Finally we can use public key A for APK authentication. >> >> So can we put a public key into the SPL and use it to verify a fitImage ? > > Technically doable. But compared with the current approach that reuse > ROM public API, Using crypto driver in SPL will be complicated and code > size larger without calling ROM API. > > I do not understand the problem the SPL loading NXP i.MX8 container format. > SPL should only support raw and fit format? vendor format is not > allowed and not accepted? The problem I have is with the duplication of functionality -- the iMX8 custom format does exactly the same as fitImage, except differently and with smaller user base, thus with less users and reviewers and thus with less potential bugfixes, which I think in crypto code is
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > On 5/30/19 9:06 AM, Ye Li wrote: > > On 2019/5/27 19:31, Marek Vasut wrote: > >> Caution: EXT Email > >> > >> On 5/27/19 11:49 AM, Peng Fan wrote: > >>> Hi Marek, Lukasz, > >>> > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > loading i.MX container format file > > Hi Marek, > > On 2019/5/22 19:41, Marek Vasut wrote: > > Caution: EXT Email > > > > On 5/22/19 9:34 AM, Lukasz Majewski wrote: > > [...] > By using above approach we do have the NXP's "container" > format only seen in the SPL (which is OK, as for example > Samsung does similar thing with FBL/BL1). When SPL is > "trused" > we may use available facilities. > >>> > >>> The issue to me is that sc_seco_authenticate could not take > >>> a FIT image as input. > >> > >> Is the sc_seco_authenticate an API accessible from SPL, > >> U-Boot proper or Linux crypro engine driver? > > > > Yes, it is an API accessible in SPL/U-Boot stage. I do not > > know about Linux crypto driver. > > Maybe it would be worth to check how Linux handle this? Maybe > it would shed some more light on it? > >>> > >>> I am not familiar with that, so might be stupid question below. > >>> Does it really matter? > >> > >> I would check it just out of curiosity. > > > > Yes, it matters, because there should be such API. How would Linux > > authenticate e.g. userspace binaries if there wasn't one, surely > > not by wrapping every single object into the custom vendor-specific > container ? > > And if there is one, you can use it to authenticate raw binaries > > from U-Boot SPL too, e.g. fitImage blobs with an associated signature. > > > > iMX8 AHAB uses RSA key pair for authentication, the on-chip thing > we called SRK is a array of public key hash which is dedicated for > AHAB. It is not a real key. The real public key is in container. > AHAB will check the public key with the on-chip SRK before using it > to authenticate the image. > Seco which contains the crypto engine on imx8 does not allow to use > the SRK by user. No such API exported. > And the fuse of SRK is locked, can't be read directly. > > Actually on imx6/imx7/imx8m, the SPL and u-boot are already using > ROM HAB to implement the trust chain, like SPL authenticates > u-boot, u-boot authenticatse kernel. We just follow this same way > on imx8, the difference is > imx8 needs container format for signed image. We prefer directly > loading container image than fit image. > If we pack fit image into container, obviously this will cause one more > copy. > As a boot loader, isn't it better to have more image format supported? > >> > >> If the functionality of the new image format is a subset of already > >> present image format, then no, that's called a duplication. > >> > We > don't force to use container, just set it as default. Users still > can choose fit or raw image. > >> > >> They can. however they cannot authenticate the fitImage because the > >> firmware doesn't provide the necessary API for that ? > >> > >>> > >>> Do you have more comment? > >> > >> How could Linux use this iMX8 chain of trust stuff to authenticate e.g. > >> userspace binaries ? It's the same thing as authenticating blob in a > >> fitImage. > >> > > > > Userspace binaries don't use the same key pair. They are signed by > > software vendors' key. The private key for chip secure boot is only hold by > device manufacturer. > > For example, android needs to authenticate a signed APK. Its public key (Key > A) is in system FS. > > iMX trust chain only reaches to kernel + ramdisk. Then the chain hands over > to android. > > In ramdisk, android puts another public Key (Key B) used by dm-verify > > for system FS. So once system FS is verified ok, then the public key A > > becomes trusted. Finally we can use public key A for APK authentication. > > So can we put a public key into the SPL and use it to verify a fitImage ? Technically doable. But compared with the current approach that reuse ROM public API, Using crypto driver in SPL will be complicated and code size larger without calling ROM API. I do not understand the problem the SPL loading NXP i.MX8 container format. SPL should only support raw and fit format? vendor format is not allowed and not accepted? Stefano, Simon, Tom Any comments? Thanks, Peng. > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 5/30/19 9:06 AM, Ye Li wrote: > On 2019/5/27 19:31, Marek Vasut wrote: >> Caution: EXT Email >> >> On 5/27/19 11:49 AM, Peng Fan wrote: >>> Hi Marek, Lukasz, >>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file Hi Marek, On 2019/5/22 19:41, Marek Vasut wrote: > Caution: EXT Email > > On 5/22/19 9:34 AM, Lukasz Majewski wrote: > [...] By using above approach we do have the NXP's "container" format only seen in the SPL (which is OK, as for example Samsung does similar thing with FBL/BL1). When SPL is "trused" we may use available facilities. >>> >>> The issue to me is that sc_seco_authenticate could not take a >>> FIT image as input. >> >> Is the sc_seco_authenticate an API accessible from SPL, U-Boot >> proper or Linux crypro engine driver? > > Yes, it is an API accessible in SPL/U-Boot stage. I do not know > about Linux crypto driver. Maybe it would be worth to check how Linux handle this? Maybe it would shed some more light on it? >>> >>> I am not familiar with that, so might be stupid question below. >>> Does it really matter? >> >> I would check it just out of curiosity. > > Yes, it matters, because there should be such API. How would Linux > authenticate e.g. userspace binaries if there wasn't one, surely not > by wrapping every single object into the custom vendor-specific container > ? > And if there is one, you can use it to authenticate raw binaries from > U-Boot SPL too, e.g. fitImage blobs with an associated signature. > iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called SRK is a array of public key hash which is dedicated for AHAB. It is not a real key. The real public key is in container. AHAB will check the public key with the on-chip SRK before using it to authenticate the image. Seco which contains the crypto engine on imx8 does not allow to use the SRK by user. No such API exported. And the fuse of SRK is locked, can't be read directly. Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM HAB to implement the trust chain, like SPL authenticates u-boot, u-boot authenticatse kernel. We just follow this same way on imx8, the difference is imx8 needs container format for signed image. We prefer directly loading container image than fit image. If we pack fit image into container, obviously this will cause one more copy. As a boot loader, isn't it better to have more image format supported? >> >> If the functionality of the new image format is a subset of already >> present image format, then no, that's called a duplication. >> We don't force to use container, just set it as default. Users still can choose fit or raw image. >> >> They can. however they cannot authenticate the fitImage because the >> firmware doesn't provide the necessary API for that ? >> >>> >>> Do you have more comment? >> >> How could Linux use this iMX8 chain of trust stuff to authenticate e.g. >> userspace binaries ? It's the same thing as authenticating blob in a >> fitImage. >> > > Userspace binaries don't use the same key pair. They are signed by software > vendors' key. The private > key for chip secure boot is only hold by device manufacturer. > For example, android needs to authenticate a signed APK. Its public key (Key > A) is in system FS. > iMX trust chain only reaches to kernel + ramdisk. Then the chain hands over > to android. > In ramdisk, android puts another public Key (Key B) used by dm-verify for > system FS. So once > system FS is verified ok, then the public key A becomes trusted. Finally we > can use public key A for > APK authentication. So can we put a public key into the SPL and use it to verify a fitImage ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 2019/5/27 19:31, Marek Vasut wrote: > Caution: EXT Email > > On 5/27/19 11:49 AM, Peng Fan wrote: >> Hi Marek, Lukasz, >> >>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX >>> container format file >>> >>> Hi Marek, >>> >>> On 2019/5/22 19:41, Marek Vasut wrote: Caution: EXT Email On 5/22/19 9:34 AM, Lukasz Majewski wrote: [...] >>> By using above approach we do have the NXP's "container" >>> format only seen in the SPL (which is OK, as for example >>> Samsung does similar thing with FBL/BL1). When SPL is "trused" >>> we may use available facilities. >> >> The issue to me is that sc_seco_authenticate could not take a >> FIT image as input. > > Is the sc_seco_authenticate an API accessible from SPL, U-Boot > proper or Linux crypro engine driver? Yes, it is an API accessible in SPL/U-Boot stage. I do not know about Linux crypto driver. >>> >>> Maybe it would be worth to check how Linux handle this? Maybe it >>> would shed some more light on it? >> >> I am not familiar with that, so might be stupid question below. >> Does it really matter? > > I would check it just out of curiosity. Yes, it matters, because there should be such API. How would Linux authenticate e.g. userspace binaries if there wasn't one, surely not by wrapping every single object into the custom vendor-specific container ? And if there is one, you can use it to authenticate raw binaries from U-Boot SPL too, e.g. fitImage blobs with an associated signature. >>> >>> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called >>> SRK is a array of public key hash which is dedicated for AHAB. It is not a >>> real >>> key. The real public key is in container. >>> AHAB will check the public key with the on-chip SRK before using it to >>> authenticate the image. >>> Seco which contains the crypto engine on imx8 does not allow to use the SRK >>> by user. No such API exported. >>> And the fuse of SRK is locked, can't be read directly. >>> >>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM >>> HAB to implement the trust chain, like SPL authenticates u-boot, u-boot >>> authenticatse kernel. We just follow this same way on imx8, the difference >>> is >>> imx8 needs container format for signed image. We prefer directly loading >>> container image than fit image. >>> If we pack fit image into container, obviously this will cause one more >>> copy. >>> As a boot loader, isn't it better to have more image format supported? > > If the functionality of the new image format is a subset of already > present image format, then no, that's called a duplication. > >>> We >>> don't force to use container, just set it as default. Users still can >>> choose fit or >>> raw image. > > They can. however they cannot authenticate the fitImage because the > firmware doesn't provide the necessary API for that ? > >> >> Do you have more comment? > > How could Linux use this iMX8 chain of trust stuff to authenticate e.g. > userspace binaries ? It's the same thing as authenticating blob in a > fitImage. > Userspace binaries don't use the same key pair. They are signed by software vendors' key. The private key for chip secure boot is only hold by device manufacturer. For example, android needs to authenticate a signed APK. Its public key (Key A) is in system FS. iMX trust chain only reaches to kernel + ramdisk. Then the chain hands over to android. In ramdisk, android puts another public Key (Key B) used by dm-verify for system FS. So once system FS is verified ok, then the public key A becomes trusted. Finally we can use public key A for APK authentication. Best regards, Ye Li > -- > Best regards, > Marek Vasut > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 5/27/19 11:49 AM, Peng Fan wrote: > Hi Marek, Lukasz, > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX >> container format file >> >> Hi Marek, >> >> On 2019/5/22 19:41, Marek Vasut wrote: >>> Caution: EXT Email >>> >>> On 5/22/19 9:34 AM, Lukasz Majewski wrote: >>> [...] >> By using above approach we do have the NXP's "container" >> format only seen in the SPL (which is OK, as for example >> Samsung does similar thing with FBL/BL1). When SPL is "trused" >> we may use available facilities. > > The issue to me is that sc_seco_authenticate could not take a > FIT image as input. Is the sc_seco_authenticate an API accessible from SPL, U-Boot proper or Linux crypro engine driver? >>> >>> Yes, it is an API accessible in SPL/U-Boot stage. I do not know >>> about Linux crypto driver. >> >> Maybe it would be worth to check how Linux handle this? Maybe it >> would shed some more light on it? > > I am not familiar with that, so might be stupid question below. > Does it really matter? I would check it just out of curiosity. >>> >>> Yes, it matters, because there should be such API. How would Linux >>> authenticate e.g. userspace binaries if there wasn't one, surely not >>> by wrapping every single object into the custom vendor-specific container ? >>> And if there is one, you can use it to authenticate raw binaries from >>> U-Boot SPL too, e.g. fitImage blobs with an associated signature. >>> >> >> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called >> SRK is a array of public key hash which is dedicated for AHAB. It is not a >> real >> key. The real public key is in container. >> AHAB will check the public key with the on-chip SRK before using it to >> authenticate the image. >> Seco which contains the crypto engine on imx8 does not allow to use the SRK >> by user. No such API exported. >> And the fuse of SRK is locked, can't be read directly. >> >> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM >> HAB to implement the trust chain, like SPL authenticates u-boot, u-boot >> authenticatse kernel. We just follow this same way on imx8, the difference is >> imx8 needs container format for signed image. We prefer directly loading >> container image than fit image. >> If we pack fit image into container, obviously this will cause one more copy. >> As a boot loader, isn't it better to have more image format supported? If the functionality of the new image format is a subset of already present image format, then no, that's called a duplication. >> We >> don't force to use container, just set it as default. Users still can choose >> fit or >> raw image. They can. however they cannot authenticate the fitImage because the firmware doesn't provide the necessary API for that ? > > Do you have more comment? How could Linux use this iMX8 chain of trust stuff to authenticate e.g. userspace binaries ? It's the same thing as authenticating blob in a fitImage. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Marek, Lukasz, > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > Hi Marek, > > On 2019/5/22 19:41, Marek Vasut wrote: > > Caution: EXT Email > > > > On 5/22/19 9:34 AM, Lukasz Majewski wrote: > > [...] > By using above approach we do have the NXP's "container" > format only seen in the SPL (which is OK, as for example > Samsung does similar thing with FBL/BL1). When SPL is "trused" > we may use available facilities. > >>> > >>> The issue to me is that sc_seco_authenticate could not take a > >>> FIT image as input. > >> > >> Is the sc_seco_authenticate an API accessible from SPL, U-Boot > >> proper or Linux crypro engine driver? > > > > Yes, it is an API accessible in SPL/U-Boot stage. I do not know > > about Linux crypto driver. > > Maybe it would be worth to check how Linux handle this? Maybe it > would shed some more light on it? > >>> > >>> I am not familiar with that, so might be stupid question below. > >>> Does it really matter? > >> > >> I would check it just out of curiosity. > > > > Yes, it matters, because there should be such API. How would Linux > > authenticate e.g. userspace binaries if there wasn't one, surely not > > by wrapping every single object into the custom vendor-specific container ? > > And if there is one, you can use it to authenticate raw binaries from > > U-Boot SPL too, e.g. fitImage blobs with an associated signature. > > > > iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called > SRK is a array of public key hash which is dedicated for AHAB. It is not a > real > key. The real public key is in container. > AHAB will check the public key with the on-chip SRK before using it to > authenticate the image. > Seco which contains the crypto engine on imx8 does not allow to use the SRK > by user. No such API exported. > And the fuse of SRK is locked, can't be read directly. > > Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM > HAB to implement the trust chain, like SPL authenticates u-boot, u-boot > authenticatse kernel. We just follow this same way on imx8, the difference is > imx8 needs container format for signed image. We prefer directly loading > container image than fit image. > If we pack fit image into container, obviously this will cause one more copy. > As a boot loader, isn't it better to have more image format supported? We > don't force to use container, just set it as default. Users still can choose > fit or > raw image. Do you have more comment? Thanks, Peng. > > > > [...] > > > > -- > > Best regards, > > Marek Vasut > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Marek, On 2019/5/22 19:41, Marek Vasut wrote: > Caution: EXT Email > > On 5/22/19 9:34 AM, Lukasz Majewski wrote: > [...] By using above approach we do have the NXP's "container" format only seen in the SPL (which is OK, as for example Samsung does similar thing with FBL/BL1). When SPL is "trused" we may use available facilities. >>> >>> The issue to me is that sc_seco_authenticate could not take a >>> FIT image as input. >> >> Is the sc_seco_authenticate an API accessible from SPL, U-Boot >> proper or Linux crypro engine driver? > > Yes, it is an API accessible in SPL/U-Boot stage. I do not know > about Linux crypto driver. Maybe it would be worth to check how Linux handle this? Maybe it would shed some more light on it? >>> >>> I am not familiar with that, so might be stupid question below. >>> Does it really matter? >> >> I would check it just out of curiosity. > > Yes, it matters, because there should be such API. How would Linux > authenticate e.g. userspace binaries if there wasn't one, surely not by > wrapping every single object into the custom vendor-specific container ? > And if there is one, you can use it to authenticate raw binaries from > U-Boot SPL too, e.g. fitImage blobs with an associated signature. > iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called SRK is a array of public key hash which is dedicated for AHAB. It is not a real key. The real public key is in container. AHAB will check the public key with the on-chip SRK before using it to authenticate the image. Seco which contains the crypto engine on imx8 does not allow to use the SRK by user. No such API exported. And the fuse of SRK is locked, can't be read directly. Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM HAB to implement the trust chain, like SPL authenticates u-boot, u-boot authenticatse kernel. We just follow this same way on imx8, the difference is imx8 needs container format for signed image. We prefer directly loading container image than fit image. If we pack fit image into container, obviously this will cause one more copy. As a boot loader, isn't it better to have more image format supported? We don't force to use container, just set it as default. Users still can choose fit or raw image. > [...] > > -- > Best regards, > Marek Vasut > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
