Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
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. [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Peng, > > > > > > > > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support > > > > > > > > loading i.MX container format file > > > > > > > > > > > > > > > > On 5/21/19 4:55 AM, Peng Fan wrote: > > > > > > > > [...] > > > > > > > > > > > > > > > > >>>>> I do not know how other SoC vendor did FIT > > > > > > > > >>>>> hardware secure boot, please share you have any > > > > > > > > >>>>> information. > > > > > > > > >>>> > > > > > > > > >>>> The SPL can be in the custom format, but then can > > > > > > > > >>>> load fitImage with the next stage(s), right ? > > > > > > > > >>> > > > > > > > > >>> I am not able to follow you, could you share more > > > > > > > > >>> details? > > > > > > > > >> > > > > > > > > >> Wrap the SPL into this custom format and then have > > > > > > > > >> the SPL load/authenticate fitImage with the rest > > > > > > > > >> (U-Boot, Linux, DTB etc). Would that work ? > > > > > > > > > > > > > > > > > > It not work. > > > > > > > > > We already wrap SPL in i.MX container format, this > > > > > > > > > patchset is to let SPL could load the 2nd container > > > > > > > > > file which contains U-Boot/DTB/OP-TEE/ATF. If we let > > > > > > > > > SPL load a fitimage which contains (U-Boot/DTB and > > > > > > > > > etc), it could not pass secure boot authentication, > > > > > > > > > because ROM not know fitimage, it only know i.MX > > > > > > > > > container format. > > > > > > > > > > > > > > > > It's not bootrom that authenticates the next stage, it's > > > > > > > > U-Boot SPL. BootROM already authenticated and started > > > > > > > > the U-Boot SPL, so that's a trusted code. Now this > > > > > > > > trusted code can authenticate and start the next stage > > > > > > > > (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already > > > > > > > > out of the picture at this point. > > > > > > > > > > > > > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware > > > > > > > )exports API for others to use, sc_seco_authenticate is > > > > > > > the API that used for authentication. I could not share > > > > > > > more information about this API works inside SCFW and > > > > > > > ROM. sc_err_t sc_seco_authenticate(sc_ipc_t ipc, > > > > > > > sc_seco_auth_cmd_t cmd, sc_faddr_t addr) > > > > > > > > > > > > > > SPL will call this API, one parameter is address which > > > > > > > needs a container image there. > > > > > > > > > > > > Please consider following scenario (I think that this is in > > > > > > sync with Marek's point): > > > > > > > > > > > > 1. You wrap SPL into i.MX8 "container", so the SPL would be > > > > > > recognised an checked by secure code in ROM. > > > > > > > > > > > > 2. Then we do have SPL "trusted". It is up to SPL to: > > > > > > > > > > > > 2.1. Use its private key to check u-boot, dtb, etc embedded > > > > > > into FitImage (as written > > > > > > here: ./doc/uImage.FIT/verified-boot.txt). > > > > > > > > > > > > 2.2. Use crypto engine (it's API) with fused keys to > > > > > > speed-up the process of boot (by HW support to check the > > > > > > binary). Such approach is in i.MX6Q. > > > > > > > > > > I suppose you talking HAB. > > > > > > > > Yes. As described here: > > > > > > > > https://www.nxp.com/docs/en/application-note/AN4581.pdf > > > > > > > > > > > > > > > > > > > > > > > > > &
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
> > > > > > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading > > > > > > > i.MX container format file > > > > > > > > > > > > > > On 5/21/19 4:55 AM, Peng Fan wrote: > > > > > > > [...] > > > > > > > > > > > > > > >>>>> I do not know how other SoC vendor did FIT hardware > > > > > > > >>>>> secure boot, please share you have any information. > > > > > > > >>>> > > > > > > > >>>> The SPL can be in the custom format, but then can load > > > > > > > >>>> fitImage with the next stage(s), right ? > > > > > > > >>> > > > > > > > >>> I am not able to follow you, could you share more > > > > > > > >>> details? > > > > > > > >> > > > > > > > >> Wrap the SPL into this custom format and then have the > > > > > > > >> SPL load/authenticate fitImage with the rest (U-Boot, > > > > > > > >> Linux, DTB etc). Would that work ? > > > > > > > > > > > > > > > > It not work. > > > > > > > > We already wrap SPL in i.MX container format, this > > > > > > > > patchset is to let SPL could load the 2nd container file > > > > > > > > which contains U-Boot/DTB/OP-TEE/ATF. If we let SPL load > > > > > > > > a fitimage which contains (U-Boot/DTB and etc), it could > > > > > > > > not pass secure boot authentication, because ROM not know > > > > > > > > fitimage, it only know i.MX container format. > > > > > > > > > > > > > > It's not bootrom that authenticates the next stage, it's > > > > > > > U-Boot SPL. BootROM already authenticated and started the > > > > > > > U-Boot SPL, so that's a trusted code. Now this trusted code > > > > > > > can authenticate and start the next stage (U-Boot, ATF, > > > > > > > OpTee OS, etc) ; the BootROM is already out of the picture > > > > > > > at this point. > > > > > > > > > > > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware > > > > > > )exports API for others to use, sc_seco_authenticate is the > > > > > > API that used for authentication. I could not share more > > > > > > information about this API works inside SCFW and ROM. sc_err_t > > > > > > sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd, > > > > > > sc_faddr_t addr) > > > > > > > > > > > > SPL will call this API, one parameter is address which needs a > > > > > > container image there. > > > > > > > > > > Please consider following scenario (I think that this is in sync > > > > > with Marek's point): > > > > > > > > > > 1. You wrap SPL into i.MX8 "container", so the SPL would be > > > > > recognised an checked by secure code in ROM. > > > > > > > > > > 2. Then we do have SPL "trusted". It is up to SPL to: > > > > > > > > > > 2.1. Use its private key to check u-boot, dtb, etc embedded into > > > > > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt). > > > > > > > > > > 2.2. Use crypto engine (it's API) with fused keys to speed-up > > > > > the process of boot (by HW support to check the binary). Such > > > > > approach is in i.MX6Q. > > > > > > > > I suppose you talking HAB. > > > > > > Yes. As described here: > > > > > > https://www.nxp.com/docs/en/application-note/AN4581.pdf > > > > > > > > > > > > > > > > > > > > > > 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 accessib
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Peng, > > > > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading > > > > > > i.MX container format file > > > > > > > > > > > > On 5/21/19 4:55 AM, Peng Fan wrote: > > > > > > [...] > > > > > > > > > > > > >>>>> I do not know how other SoC vendor did FIT hardware > > > > > > >>>>> secure boot, please share you have any information. > > > > > > >>>> > > > > > > >>>> The SPL can be in the custom format, but then can load > > > > > > >>>> fitImage with the next stage(s), right ? > > > > > > >>> > > > > > > >>> I am not able to follow you, could you share more > > > > > > >>> details? > > > > > > >> > > > > > > >> Wrap the SPL into this custom format and then have the > > > > > > >> SPL load/authenticate fitImage with the rest (U-Boot, > > > > > > >> Linux, DTB etc). Would that work ? > > > > > > > > > > > > > > It not work. > > > > > > > We already wrap SPL in i.MX container format, this > > > > > > > patchset is to let SPL could load the 2nd container file > > > > > > > which contains U-Boot/DTB/OP-TEE/ATF. If we let SPL load > > > > > > > a fitimage which contains (U-Boot/DTB and etc), it could > > > > > > > not pass secure boot authentication, because ROM not know > > > > > > > fitimage, it only know i.MX container format. > > > > > > > > > > > > It's not bootrom that authenticates the next stage, it's > > > > > > U-Boot SPL. BootROM already authenticated and started the > > > > > > U-Boot SPL, so that's a trusted code. Now this trusted code > > > > > > can authenticate and start the next stage (U-Boot, ATF, > > > > > > OpTee OS, etc) ; the BootROM is already out of the picture > > > > > > at this point. > > > > > > > > > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware > > > > > )exports API for others to use, sc_seco_authenticate is the > > > > > API that used for authentication. I could not share more > > > > > information about this API works inside SCFW and ROM. sc_err_t > > > > > sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd, > > > > > sc_faddr_t addr) > > > > > > > > > > SPL will call this API, one parameter is address which needs a > > > > > container image there. > > > > > > > > Please consider following scenario (I think that this is in sync > > > > with Marek's point): > > > > > > > > 1. You wrap SPL into i.MX8 "container", so the SPL would be > > > > recognised an checked by secure code in ROM. > > > > > > > > 2. Then we do have SPL "trusted". It is up to SPL to: > > > > > > > > 2.1. Use its private key to check u-boot, dtb, etc embedded into > > > > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt). > > > > > > > > 2.2. Use crypto engine (it's API) with fused keys to speed-up > > > > the process of boot (by HW support to check the binary). Such > > > > approach is in i.MX6Q. > > > > > > I suppose you talking HAB. > > > > Yes. As described here: > > > > https://www.nxp.com/docs/en/application-note/AN4581.pdf > > > > > > > > > > > > > > > > > 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? > > > > > Or is it just the functi
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
> > > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > > > > > container format file > > > > > > > > > > On 5/21/19 4:55 AM, Peng Fan wrote: > > > > > [...] > > > > > > > > > > >>>>> I do not know how other SoC vendor did FIT hardware secure > > > > > >>>>> boot, please share you have any information. > > > > > >>>> > > > > > >>>> The SPL can be in the custom format, but then can load > > > > > >>>> fitImage with the next stage(s), right ? > > > > > >>> > > > > > >>> I am not able to follow you, could you share more details? > > > > > >> > > > > > >> Wrap the SPL into this custom format and then have the SPL > > > > > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB > > > > > >> etc). Would that work ? > > > > > > > > > > > > It not work. > > > > > > We already wrap SPL in i.MX container format, this patchset is > > > > > > to let SPL could load the 2nd container file which contains > > > > > > U-Boot/DTB/OP-TEE/ATF. If we let SPL load a fitimage which > > > > > > contains (U-Boot/DTB and etc), it could not pass secure boot > > > > > > authentication, because ROM not know fitimage, it only know > > > > > > i.MX container format. > > > > > > > > > > It's not bootrom that authenticates the next stage, it's U-Boot > > > > > SPL. BootROM already authenticated and started the U-Boot SPL, > > > > > so that's a trusted code. Now this trusted code can authenticate > > > > > and start the next stage (U-Boot, ATF, OpTee OS, > > > > > etc) ; the BootROM is already out of the picture at this point. > > > > > > > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports > > > > API for others to use, sc_seco_authenticate is the API that used > > > > for authentication. I could not share more information about this > > > > API works inside SCFW and ROM. sc_err_t > > > > sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd, > > > > sc_faddr_t addr) > > > > > > > > SPL will call this API, one parameter is address which needs a > > > > container image there. > > > > > > Please consider following scenario (I think that this is in sync > > > with Marek's point): > > > > > > 1. You wrap SPL into i.MX8 "container", so the SPL would be > > > recognised an checked by secure code in ROM. > > > > > > 2. Then we do have SPL "trusted". It is up to SPL to: > > > > > > 2.1. Use its private key to check u-boot, dtb, etc embedded into > > > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt). > > > > > > 2.2. Use crypto engine (it's API) with fused keys to speed-up the > > > process of boot (by HW support to check the binary). Such approach > > > is in i.MX6Q. > > > > I suppose you talking HAB. > > Yes. As described here: > > https://www.nxp.com/docs/en/application-note/AN4581.pdf > > > > > > > > > > > > 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. > > Or is it just the function executed by ROM on the very beginning to load SPL? > > > > > If I switch to FIT, I need to use FIT to wrap a container image, it > > does not make sense to me. > > Please correct me if I'm wrong, but isn't the container image only needed to > wrap SPL? Container image will wrap SPL to make ROM could load SPL, Kick SPL and authenticate SPL. When SPL booting U-Boot, SPL could use FIT to load and boot uboot. But when SPL need to authenticate U-Boot with AHAB on i.MX8, a container format header/image needs to be passed to sc_seco_authenticate API, the API internal implementation is it will parse
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Peng, > Hi Lukasz, > > > -Original Message- > > From: Lukasz Majewski [mailto:lu...@denx.de] > > Sent: 2019年5月21日 16:33 > > To: Peng Fan > > Cc: Marek Vasut ; Marek Vasut > > ; Simon Glass ; > > u-boot@lists.denx.de; Tien Fong Chee ; > > York Sun ; dl-uboot-imx > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > > container format file > > > > Hi Peng, > > > > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > > > > container format file > > > > > > > > On 5/21/19 4:55 AM, Peng Fan wrote: > > > > [...] > > > > > > > > >>>>> I do not know how other SoC vendor did FIT hardware secure > > > > >>>>> boot, please share you have any information. > > > > >>>> > > > > >>>> The SPL can be in the custom format, but then can load > > > > >>>> fitImage with the next stage(s), right ? > > > > >>> > > > > >>> I am not able to follow you, could you share more details? > > > > >> > > > > >> Wrap the SPL into this custom format and then have the SPL > > > > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB > > > > >> etc). Would that work ? > > > > > > > > > > It not work. > > > > > We already wrap SPL in i.MX container format, this patchset > > > > > is to let SPL could load the 2nd container file which contains > > > > > U-Boot/DTB/OP-TEE/ATF. If we let SPL load a fitimage which > > > > > contains (U-Boot/DTB and etc), it could not pass secure boot > > > > > authentication, because ROM not know fitimage, it only know > > > > > i.MX container format. > > > > > > > > It's not bootrom that authenticates the next stage, it's U-Boot > > > > SPL. BootROM already authenticated and started the U-Boot SPL, > > > > so that's a trusted code. Now this trusted code can > > > > authenticate and start the next stage (U-Boot, ATF, OpTee OS, > > > > etc) ; the BootROM is already out of the picture at this > > > > point. > > > > > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports > > > API for others to use, sc_seco_authenticate is the API that used > > > for authentication. I could not share more information about this > > > API works inside SCFW and ROM. sc_err_t > > > sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd, > > > sc_faddr_t addr) > > > > > > SPL will call this API, one parameter is address which needs a > > > container image there. > > > > Please consider following scenario (I think that this is in sync > > with Marek's point): > > > > 1. You wrap SPL into i.MX8 "container", so the SPL would be > > recognised an checked by secure code in ROM. > > > > 2. Then we do have SPL "trusted". It is up to SPL to: > > > > 2.1. Use its private key to check u-boot, dtb, etc embedded into > > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt). > > > > 2.2. Use crypto engine (it's API) with fused keys to speed-up the > > process of boot (by HW support to check the binary). Such approach > > is in i.MX6Q. > > I suppose you talking HAB. Yes. As described here: https://www.nxp.com/docs/en/application-note/AN4581.pdf > > > > > > > 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? Or is it just the function executed by ROM on the very beginning to load SPL? > > If I switch to FIT, I need to use FIT to wrap a container image, it > does not make sense to me. Please correct me if I'm wrong, but isn't the container image only needed to wrap SPL? In which other cases the container image is needed in U-Boot proper or Linux kernel? > > Thanks, > Peng. > > > > > > > > > > > > > > For authentication, we always let ROM to authenticate > > > > > including SPL authenticating U-Boot, so we need pass an image > >
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Lukasz, > -Original Message- > From: Lukasz Majewski [mailto:lu...@denx.de] > Sent: 2019年5月21日 16:33 > To: Peng Fan > Cc: Marek Vasut ; Marek Vasut ; > Simon Glass ; u-boot@lists.denx.de; Tien Fong Chee > ; York Sun ; dl-uboot-imx > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container > format file > > Hi Peng, > > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > > > container format file > > > > > > On 5/21/19 4:55 AM, Peng Fan wrote: > > > [...] > > > > > > >>>>> I do not know how other SoC vendor did FIT hardware secure > > > >>>>> boot, please share you have any information. > > > >>>> > > > >>>> The SPL can be in the custom format, but then can load fitImage > > > >>>> with the next stage(s), right ? > > > >>> > > > >>> I am not able to follow you, could you share more details? > > > >> > > > >> Wrap the SPL into this custom format and then have the SPL > > > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB > > > >> etc). Would that work ? > > > > > > > > It not work. > > > > We already wrap SPL in i.MX container format, this patchset is to > > > > let SPL could load the 2nd container file which contains > > > > U-Boot/DTB/OP-TEE/ATF. If we let SPL load a fitimage which > > > > contains (U-Boot/DTB and etc), it could not pass secure boot > > > > authentication, because ROM not know fitimage, it only know i.MX > > > > container format. > > > > > > It's not bootrom that authenticates the next stage, it's U-Boot SPL. > > > BootROM already authenticated and started the U-Boot SPL, so that's > > > a trusted code. Now this trusted code can authenticate and start the > > > next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already out > > > of the picture at this point. > > > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API > > for others to use, sc_seco_authenticate is the API that used for > > authentication. I could not share more information about this API > > works inside SCFW and ROM. sc_err_t sc_seco_authenticate(sc_ipc_t ipc, > > sc_seco_auth_cmd_t cmd, sc_faddr_t addr) > > > > SPL will call this API, one parameter is address which needs a > > container image there. > > Please consider following scenario (I think that this is in sync with Marek's > point): > > 1. You wrap SPL into i.MX8 "container", so the SPL would be recognised an > checked by secure code in ROM. > > 2. Then we do have SPL "trusted". It is up to SPL to: > > 2.1. Use its private key to check u-boot, dtb, etc embedded into FitImage (as > written here: ./doc/uImage.FIT/verified-boot.txt). > > 2.2. Use crypto engine (it's API) with fused keys to speed-up the process of > boot (by HW support to check the binary). Such approach is in i.MX6Q. I suppose you talking HAB. > > > 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. If I switch to FIT, I need to use FIT to wrap a container image, it does not make sense to me. Thanks, Peng. > > > > > > > > > > For authentication, we always let ROM to authenticate including > > > > SPL authenticating U-Boot, so we need pass an image to ROM that > > > > ROM could recognize when SPL booting 2nd image. > > > > > > Shouldn't the CPU have some sort of facility, like a crypto engine, > > > which authenticates whatever blob with the right signature against a > > > key burned into the CPU ? If so, then you would just implement a > > > crypto driver and pass the blob and signature to it. I suspect > > > that's how it should work, how else would Linux be able to make use > > > of these secure bits if it cannot call the bootrom anymore ? > > > > sc_seco_authenticate on i.MX8 will always be available. It is exported > > by a runtime firmware running on a Cortex-M core inside i.MX8. The API > > will do authentication, its accepts container format image as input > > and no other format. > > > > Thanks, > > Peng. > > > > > > > > -- > > > Best regards, > > > Marek Vasut > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > > > > 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 U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Simon, > Subject: RE: [PATCH 4/6] spl: mmc: support loading i.MX container format file > > Hi Simon, > > > Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container > > format file > > > > Hi Peng, > > > > On Tue, 7 May 2019 at 06:52, Peng Fan wrote: > > > > > > i.MX8 only support AHAB secure boot with Container format image, we > > > could not use FIT to support secure boot, so introduce container > > > > Why not FIT? > > Actually before we implement secure boot, we use FIT image, however > i.MX8 only support i.MX container format image for secure boot, The chip will > verify the container image when secure boot. It could not recognize FIT image. > So we have to drop FIT image. > > > > > > support to let SPL could load container images. > > > > What is a container image? Can you please point to documentation? > > Sadly, there is no public reference manual. There is a doc that has a bit of > information. https://community.nxp.com/docs/DOC-343178 https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf Chapter 5.9.4 High Level Container Format Thanks, Peng. > > Thanks, > Peng. > > > > > > > > > Cc: Simon Goldschmidt > > > Cc: Tien Fong Chee > > > Cc: York Sun > > > Cc: Marek Vasut > > > Cc: Alex Kiernan > > > Cc: Simon Glass > > > Cc: Philipp Tomsich > > > Cc: Kever Yang > > > Cc: Heiko Schocher > > > Signed-off-by: Peng Fan > > > --- > > > common/spl/spl_mmc.c | 10 ++ > > > include/spl.h| 12 > > > 2 files changed, 22 insertions(+) > > > > Regards, > > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Marek, > On 5/21/19 10:32 AM, Lukasz Majewski wrote: > > Hi Peng, > > > >>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > >>> container format file > >>> > >>> On 5/21/19 4:55 AM, Peng Fan wrote: > >>> [...] > >>> > >>>>>>>> I do not know how other SoC vendor did FIT hardware secure > >>>>>>>> boot, please share you have any information. > >>>>>>> > >>>>>>> The SPL can be in the custom format, but then can load > >>>>>>> fitImage with the next stage(s), right ? > >>>>>> > >>>>>> I am not able to follow you, could you share more details? > >>>>> > >>>>> Wrap the SPL into this custom format and then have the SPL > >>>>> load/authenticate fitImage with the rest (U-Boot, Linux, DTB > >>>>> etc). Would that work ? > >>>> > >>>> It not work. > >>>> We already wrap SPL in i.MX container format, this patchset is to > >>>> let SPL could load the 2nd container file which contains > >>>> U-Boot/DTB/OP-TEE/ATF. If we let SPL load a fitimage which > >>>> contains (U-Boot/DTB and etc), it could not pass secure boot > >>>> authentication, because ROM not know fitimage, it only know i.MX > >>>> container format. > >>> > >>> It's not bootrom that authenticates the next stage, it's U-Boot > >>> SPL. BootROM already authenticated and started the U-Boot SPL, so > >>> that's a trusted code. Now this trusted code can authenticate and > >>> start the next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is > >>> already out of the picture at this point. > >> > >> Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports > >> API for others to use, sc_seco_authenticate is the API that used > >> for authentication. I could not share more information about this > >> API works inside SCFW and ROM. sc_err_t > >> sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd, > >> sc_faddr_t addr) > >> > >> SPL will call this API, one parameter is address which needs a > >> container image there. > > > > Please consider following scenario (I think that this is in sync > > with Marek's point): > > It's not in sync, see 2.1 below. > > > 1. You wrap SPL into i.MX8 "container", so the SPL would be > > recognised an checked by secure code in ROM. > > > > 2. Then we do have SPL "trusted". It is up to SPL to: > > > > 2.1. Use its private key to check u-boot, dtb, etc embedded into > > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt). > > Then you have two private keys, There shall be s/private key/public key/g in the SPL (but then the SPL needs to be trusted). And I fully agree that we shall use crypto engine whenever possible. > one which is potentially exposed by > being in the SPL. You want to use the crypto engine, which has a key > in it and which cannot be easily extracted. > > > 2.2. Use crypto engine (it's API) with fused keys to speed-up the > > process of boot (by HW support to check the binary). Such approach > > is in i.MX6Q. > > > > > > 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. > My question is, how can Linux crypto API make use of the built-in > private key in the iMX8 to authenticate payload ? There surely is a > way. > 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 pgp6nrMsOVXZy.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 5/21/19 10:32 AM, Lukasz Majewski wrote: > Hi Peng, > >>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX >>> container format file >>> >>> On 5/21/19 4:55 AM, Peng Fan wrote: >>> [...] >>> >>>>>>>> I do not know how other SoC vendor did FIT hardware secure >>>>>>>> boot, please share you have any information. >>>>>>> >>>>>>> The SPL can be in the custom format, but then can load fitImage >>>>>>> with the next stage(s), right ? >>>>>> >>>>>> I am not able to follow you, could you share more details? >>>>> >>>>> Wrap the SPL into this custom format and then have the SPL >>>>> load/authenticate fitImage with the rest (U-Boot, Linux, DTB >>>>> etc). Would that work ? >>>> >>>> It not work. >>>> We already wrap SPL in i.MX container format, this patchset is to >>>> let SPL could load the 2nd container file which contains >>>> U-Boot/DTB/OP-TEE/ATF. If we let SPL load a fitimage which >>>> contains (U-Boot/DTB and etc), it could not pass secure boot >>>> authentication, because ROM not know fitimage, it only know i.MX >>>> container format. >>> >>> It's not bootrom that authenticates the next stage, it's U-Boot SPL. >>> BootROM already authenticated and started the U-Boot SPL, so that's >>> a trusted code. Now this trusted code can authenticate and start >>> the next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is >>> already out of the picture at this point. >> >> Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API >> for others to use, sc_seco_authenticate is the API that used for >> authentication. I could not share more information about this API >> works inside SCFW and ROM. sc_err_t sc_seco_authenticate(sc_ipc_t >> ipc, sc_seco_auth_cmd_t cmd, sc_faddr_t addr) >> >> SPL will call this API, one parameter is address which needs a >> container image there. > > Please consider following scenario (I think that this is in sync with > Marek's point): It's not in sync, see 2.1 below. > 1. You wrap SPL into i.MX8 "container", so the SPL would be recognised > an checked by secure code in ROM. > > 2. Then we do have SPL "trusted". It is up to SPL to: > > 2.1. Use its private key to check u-boot, dtb, etc embedded into > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt). Then you have two private keys, one which is potentially exposed by being in the SPL. You want to use the crypto engine, which has a key in it and which cannot be easily extracted. > 2.2. Use crypto engine (it's API) with fused keys to speed-up the > process of boot (by HW support to check the binary). Such approach is > in i.MX6Q. > > > 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. My question is, how can Linux crypto API make use of the built-in private key in the iMX8 to authenticate payload ? There surely is a way. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Peng, > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > > container format file > > > > On 5/21/19 4:55 AM, Peng Fan wrote: > > [...] > > > > >>>>> I do not know how other SoC vendor did FIT hardware secure > > >>>>> boot, please share you have any information. > > >>>> > > >>>> The SPL can be in the custom format, but then can load fitImage > > >>>> with the next stage(s), right ? > > >>> > > >>> I am not able to follow you, could you share more details? > > >> > > >> Wrap the SPL into this custom format and then have the SPL > > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB > > >> etc). Would that work ? > > > > > > It not work. > > > We already wrap SPL in i.MX container format, this patchset is to > > > let SPL could load the 2nd container file which contains > > > U-Boot/DTB/OP-TEE/ATF. If we let SPL load a fitimage which > > > contains (U-Boot/DTB and etc), it could not pass secure boot > > > authentication, because ROM not know fitimage, it only know i.MX > > > container format. > > > > It's not bootrom that authenticates the next stage, it's U-Boot SPL. > > BootROM already authenticated and started the U-Boot SPL, so that's > > a trusted code. Now this trusted code can authenticate and start > > the next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is > > already out of the picture at this point. > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API > for others to use, sc_seco_authenticate is the API that used for > authentication. I could not share more information about this API > works inside SCFW and ROM. sc_err_t sc_seco_authenticate(sc_ipc_t > ipc, sc_seco_auth_cmd_t cmd, sc_faddr_t addr) > > SPL will call this API, one parameter is address which needs a > container image there. Please consider following scenario (I think that this is in sync with Marek's point): 1. You wrap SPL into i.MX8 "container", so the SPL would be recognised an checked by secure code in ROM. 2. Then we do have SPL "trusted". It is up to SPL to: 2.1. Use its private key to check u-boot, dtb, etc embedded into FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt). 2.2. Use crypto engine (it's API) with fused keys to speed-up the process of boot (by HW support to check the binary). Such approach is in i.MX6Q. 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. > > > > > > For authentication, we always let ROM to authenticate including > > > SPL authenticating U-Boot, so we need pass an image to ROM that > > > ROM could recognize when SPL booting 2nd image. > > > > Shouldn't the CPU have some sort of facility, like a crypto engine, > > which authenticates whatever blob with the right signature against > > a key burned into the CPU ? If so, then you would just implement a > > crypto driver and pass the blob and signature to it. I suspect > > that's how it should work, how else would Linux be able to make use > > of these secure bits if it cannot call the bootrom anymore ? > > sc_seco_authenticate on i.MX8 will always be available. It is > exported by a runtime firmware running on a Cortex-M core inside > i.MX8. The API will do authentication, its accepts container format > image as input and no other format. > > Thanks, > Peng. > > > > > -- > > Best regards, > > Marek Vasut > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot 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 pgpPb1DKLz0Yd.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container > format file > > On 5/21/19 4:55 AM, Peng Fan wrote: > [...] > > >>>>> I do not know how other SoC vendor did FIT hardware secure boot, > >>>>> please share you have any information. > >>>> > >>>> The SPL can be in the custom format, but then can load fitImage > >>>> with the next stage(s), right ? > >>> > >>> I am not able to follow you, could you share more details? > >> > >> Wrap the SPL into this custom format and then have the SPL > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc). > >> Would that work ? > > > > It not work. > > We already wrap SPL in i.MX container format, this patchset is to let > > SPL could load the 2nd container file which contains > > U-Boot/DTB/OP-TEE/ATF. If we let SPL load a fitimage which contains > > (U-Boot/DTB and etc), it could not pass secure boot authentication, > > because ROM not know fitimage, it only know i.MX container format. > > It's not bootrom that authenticates the next stage, it's U-Boot SPL. > BootROM already authenticated and started the U-Boot SPL, so that's a > trusted code. Now this trusted code can authenticate and start the next stage > (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already out of the picture at > this point. Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API for others to use, sc_seco_authenticate is the API that used for authentication. I could not share more information about this API works inside SCFW and ROM. sc_err_t sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd, sc_faddr_t addr) SPL will call this API, one parameter is address which needs a container image there. > > > For authentication, we always let ROM to authenticate including SPL > > authenticating U-Boot, so we need pass an image to ROM that ROM could > > recognize when SPL booting 2nd image. > > Shouldn't the CPU have some sort of facility, like a crypto engine, which > authenticates whatever blob with the right signature against a key burned into > the CPU ? If so, then you would just implement a crypto driver and pass the > blob and signature to it. I suspect that's how it should work, how else would > Linux be able to make use of these secure bits if it cannot call the bootrom > anymore ? sc_seco_authenticate on i.MX8 will always be available. It is exported by a runtime firmware running on a Cortex-M core inside i.MX8. The API will do authentication, its accepts container format image as input and no other format. 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] [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 5/21/19 4:55 AM, Peng Fan wrote: [...] > I do not know how other SoC vendor did FIT hardware secure boot, > please share you have any information. The SPL can be in the custom format, but then can load fitImage with the next stage(s), right ? >>> >>> I am not able to follow you, could you share more details? >> >> Wrap the SPL into this custom format and then have the SPL >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc). >> Would that work ? > > It not work. > We already wrap SPL in i.MX container format, this patchset > is to let SPL could load the 2nd container file which contains > U-Boot/DTB/OP-TEE/ATF. If we let SPL load a fitimage which contains > (U-Boot/DTB and etc), it could not pass secure boot authentication, > because ROM not know fitimage, it only know i.MX container format. It's not bootrom that authenticates the next stage, it's U-Boot SPL. BootROM already authenticated and started the U-Boot SPL, so that's a trusted code. Now this trusted code can authenticate and start the next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already out of the picture at this point. > For authentication, we always let ROM to authenticate including > SPL authenticating U-Boot, so we need pass an image to ROM that ROM > could recognize when SPL booting 2nd image. Shouldn't the CPU have some sort of facility, like a crypto engine, which authenticates whatever blob with the right signature against a key burned into the CPU ? If so, then you would just implement a crypto driver and pass the blob and signature to it. I suspect that's how it should work, how else would Linux be able to make use of these secure bits if it cannot call the bootrom anymore ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Marek, > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container > format file > > On 5/21/19 4:31 AM, Peng Fan wrote: > > Hi Marek, > > > >> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > >> container format file > >> > >> On 5/20/19 3:54 AM, Peng Fan wrote: > >>> Hi Marek, > >>> > >>>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > >>>> container format file > >>>> > >>>> On 5/20/19 3:30 AM, Peng Fan wrote: > >>>>> Hi Simon, > >>>>> > >>>>>> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container > >>>>>> format file > >>>>>> > >>>>>> Hi Peng, > >>>>>> > >>>>>> On Tue, 7 May 2019 at 06:52, Peng Fan wrote: > >>>>>>> > >>>>>>> i.MX8 only support AHAB secure boot with Container format image, > >>>>>>> we could not use FIT to support secure boot, so introduce > >>>>>>> container > >>>>>> > >>>>>> Why not FIT? > >>>>> > >>>>> Actually before we implement secure boot, we use FIT image, > >>>>> however > >>>>> i.MX8 only support i.MX container format image for secure boot, > >>>>> The chip will verify the container image when secure boot. It > >>>>> could not recognize FIT image. So we have to drop FIT image. > >>>>> > >>>>>> > >>>>>>> support to let SPL could load container images. > >>>>>> > >>>>>> What is a container image? Can you please point to documentation? > >>>>> > >>>>> Sadly, there is no public reference manual. There is a doc that > >>>>> has a bit of information. > >>>>> > >>>> > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom > >>>> m > >>>>> > >>>> > >> > unity.nxp.com%2Fdocs%2FDOC-343178data=02%7C01%7Cpeng.fan%4 > >>>> 0nxp.co > >>>>> > >>>> > >> > m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9 > >>>> 9c5c30163 > >>>>> > >>>> > >> > 5%7C0%7C0%7C636939135344595378sdata=vmIaO78XmuL1tQJufqf7 > >>>> HCGdWHTCJ > >>>>> bEpmGBio15j46U%3Dreserved=0 > >>>> > >>>> Shouldn't it suffice for the SPL to be in this custom format , > >>>> while the rest of the binaries can be in fitImage ? > >>> > >>> The issue is the SoC only support i.MX container format for secure > >>> boot(AHAB boot), if we not use secure boot, FIT image do work and > >>> could > >> work well. > >>> > >>> We investigated using FIT for i.MX8 secure boot, but it does not > >>> make sense we did a FIT wrapper for container. Container itself is > >>> also an image format, it contains image load/entry/size and etc > information. > >>> > >>> I add a kconfig entry in SPL code, it does not hurt others if the > >>> Kconfig entry > >> not chosen. > >>> > >>> I do not know how other SoC vendor did FIT hardware secure boot, > >>> please share you have any information. > >> > >> The SPL can be in the custom format, but then can load fitImage with > >> the next stage(s), right ? > > > > I am not able to follow you, could you share more details? > > Wrap the SPL into this custom format and then have the SPL > load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc). > Would that work ? It not work. We already wrap SPL in i.MX container format, this patchset is to let SPL could load the 2nd container file which contains U-Boot/DTB/OP-TEE/ATF. If we let SPL load a fitimage which contains (U-Boot/DTB and etc), it could not pass secure boot authentication, because ROM not know fitimage, it only know i.MX container format. For authentication, we always let ROM to authenticate including SPL authenticating U-Boot, so we need pass an image to ROM that ROM could recognize when SPL booting 2nd image. 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] [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 5/21/19 4:31 AM, Peng Fan wrote: > Hi Marek, > >> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container >> format file >> >> On 5/20/19 3:54 AM, Peng Fan wrote: >>> Hi Marek, >>> >>>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX >>>> container format file >>>> >>>> On 5/20/19 3:30 AM, Peng Fan wrote: >>>>> Hi Simon, >>>>> >>>>>> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container >>>>>> format file >>>>>> >>>>>> Hi Peng, >>>>>> >>>>>> On Tue, 7 May 2019 at 06:52, Peng Fan wrote: >>>>>>> >>>>>>> i.MX8 only support AHAB secure boot with Container format image, >>>>>>> we could not use FIT to support secure boot, so introduce >>>>>>> container >>>>>> >>>>>> Why not FIT? >>>>> >>>>> Actually before we implement secure boot, we use FIT image, however >>>>> i.MX8 only support i.MX container format image for secure boot, The >>>>> chip will verify the container image when secure boot. It could not >>>>> recognize FIT image. So we have to drop FIT image. >>>>> >>>>>> >>>>>>> support to let SPL could load container images. >>>>>> >>>>>> What is a container image? Can you please point to documentation? >>>>> >>>>> Sadly, there is no public reference manual. There is a doc that has >>>>> a bit of information. >>>>> >>>> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom >>>> m >>>>> >>>> >> unity.nxp.com%2Fdocs%2FDOC-343178data=02%7C01%7Cpeng.fan%4 >>>> 0nxp.co >>>>> >>>> >> m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9 >>>> 9c5c30163 >>>>> >>>> >> 5%7C0%7C0%7C636939135344595378sdata=vmIaO78XmuL1tQJufqf7 >>>> HCGdWHTCJ >>>>> bEpmGBio15j46U%3Dreserved=0 >>>> >>>> Shouldn't it suffice for the SPL to be in this custom format , while >>>> the rest of the binaries can be in fitImage ? >>> >>> The issue is the SoC only support i.MX container format for secure >>> boot(AHAB boot), if we not use secure boot, FIT image do work and could >> work well. >>> >>> We investigated using FIT for i.MX8 secure boot, but it does not make >>> sense we did a FIT wrapper for container. Container itself is also an >>> image format, it contains image load/entry/size and etc information. >>> >>> I add a kconfig entry in SPL code, it does not hurt others if the Kconfig >>> entry >> not chosen. >>> >>> I do not know how other SoC vendor did FIT hardware secure boot, >>> please share you have any information. >> >> The SPL can be in the custom format, but then can load fitImage with the next >> stage(s), right ? > > I am not able to follow you, could you share more details? Wrap the SPL into this custom format and then have the SPL load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc). Would that work ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Marek, > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container > format file > > On 5/20/19 3:54 AM, Peng Fan wrote: > > Hi Marek, > > > >> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > >> container format file > >> > >> On 5/20/19 3:30 AM, Peng Fan wrote: > >>> Hi Simon, > >>> > >>>> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container > >>>> format file > >>>> > >>>> Hi Peng, > >>>> > >>>> On Tue, 7 May 2019 at 06:52, Peng Fan wrote: > >>>>> > >>>>> i.MX8 only support AHAB secure boot with Container format image, > >>>>> we could not use FIT to support secure boot, so introduce > >>>>> container > >>>> > >>>> Why not FIT? > >>> > >>> Actually before we implement secure boot, we use FIT image, however > >>> i.MX8 only support i.MX container format image for secure boot, The > >>> chip will verify the container image when secure boot. It could not > >>> recognize FIT image. So we have to drop FIT image. > >>> > >>>> > >>>>> support to let SPL could load container images. > >>>> > >>>> What is a container image? Can you please point to documentation? > >>> > >>> Sadly, there is no public reference manual. There is a doc that has > >>> a bit of information. > >>> > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom > >> m > >>> > >> > unity.nxp.com%2Fdocs%2FDOC-343178data=02%7C01%7Cpeng.fan%4 > >> 0nxp.co > >>> > >> > m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9 > >> 9c5c30163 > >>> > >> > 5%7C0%7C0%7C636939135344595378sdata=vmIaO78XmuL1tQJufqf7 > >> HCGdWHTCJ > >>> bEpmGBio15j46U%3Dreserved=0 > >> > >> Shouldn't it suffice for the SPL to be in this custom format , while > >> the rest of the binaries can be in fitImage ? > > > > The issue is the SoC only support i.MX container format for secure > > boot(AHAB boot), if we not use secure boot, FIT image do work and could > work well. > > > > We investigated using FIT for i.MX8 secure boot, but it does not make > > sense we did a FIT wrapper for container. Container itself is also an > > image format, it contains image load/entry/size and etc information. > > > > I add a kconfig entry in SPL code, it does not hurt others if the Kconfig > > entry > not chosen. > > > > I do not know how other SoC vendor did FIT hardware secure boot, > > please share you have any information. > > The SPL can be in the custom format, but then can load fitImage with the next > stage(s), right ? I am not able to follow you, could you share more details? 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] [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 5/20/19 3:54 AM, Peng Fan wrote: > Hi Marek, > >> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container >> format file >> >> On 5/20/19 3:30 AM, Peng Fan wrote: >>> Hi Simon, >>> >>>> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container >>>> format file >>>> >>>> Hi Peng, >>>> >>>> On Tue, 7 May 2019 at 06:52, Peng Fan wrote: >>>>> >>>>> i.MX8 only support AHAB secure boot with Container format image, we >>>>> could not use FIT to support secure boot, so introduce container >>>> >>>> Why not FIT? >>> >>> Actually before we implement secure boot, we use FIT image, however >>> i.MX8 only support i.MX container format image for secure boot, The >>> chip will verify the container image when secure boot. It could not >>> recognize FIT image. So we have to drop FIT image. >>> >>>> >>>>> support to let SPL could load container images. >>>> >>>> What is a container image? Can you please point to documentation? >>> >>> Sadly, there is no public reference manual. There is a doc that has a >>> bit of information. >>> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm >>> >> unity.nxp.com%2Fdocs%2FDOC-343178data=02%7C01%7Cpeng.fan%4 >> 0nxp.co >>> >> m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9 >> 9c5c30163 >>> >> 5%7C0%7C0%7C636939135344595378sdata=vmIaO78XmuL1tQJufqf7 >> HCGdWHTCJ >>> bEpmGBio15j46U%3Dreserved=0 >> >> Shouldn't it suffice for the SPL to be in this custom format , while the >> rest of >> the binaries can be in fitImage ? > > The issue is the SoC only support i.MX container format for secure boot(AHAB > boot), > if we not use secure boot, FIT image do work and could work well. > > We investigated using FIT for i.MX8 secure boot, but it does not make sense > we did a FIT wrapper for container. Container itself is also an image format, > it contains > image load/entry/size and etc information. > > I add a kconfig entry in SPL code, it does not hurt others if the Kconfig > entry not chosen. > > I do not know how other SoC vendor did FIT hardware secure boot, please share > you have any information. The SPL can be in the custom format, but then can load fitImage with the next stage(s), right ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Marek, > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container > format file > > On 5/20/19 3:30 AM, Peng Fan wrote: > > Hi Simon, > > > >> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container > >> format file > >> > >> Hi Peng, > >> > >> On Tue, 7 May 2019 at 06:52, Peng Fan wrote: > >>> > >>> i.MX8 only support AHAB secure boot with Container format image, we > >>> could not use FIT to support secure boot, so introduce container > >> > >> Why not FIT? > > > > Actually before we implement secure boot, we use FIT image, however > > i.MX8 only support i.MX container format image for secure boot, The > > chip will verify the container image when secure boot. It could not > > recognize FIT image. So we have to drop FIT image. > > > >> > >>> support to let SPL could load container images. > >> > >> What is a container image? Can you please point to documentation? > > > > Sadly, there is no public reference manual. There is a doc that has a > > bit of information. > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm > > > unity.nxp.com%2Fdocs%2FDOC-343178data=02%7C01%7Cpeng.fan%4 > 0nxp.co > > > m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9 > 9c5c30163 > > > 5%7C0%7C0%7C636939135344595378sdata=vmIaO78XmuL1tQJufqf7 > HCGdWHTCJ > > bEpmGBio15j46U%3Dreserved=0 > > Shouldn't it suffice for the SPL to be in this custom format , while the rest > of > the binaries can be in fitImage ? The issue is the SoC only support i.MX container format for secure boot(AHAB boot), if we not use secure boot, FIT image do work and could work well. We investigated using FIT for i.MX8 secure boot, but it does not make sense we did a FIT wrapper for container. Container itself is also an image format, it contains image load/entry/size and etc information. I add a kconfig entry in SPL code, it does not hurt others if the Kconfig entry not chosen. I do not know how other SoC vendor did FIT hardware secure boot, please share you have any information. 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] [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 5/20/19 3:30 AM, Peng Fan wrote: > Hi Simon, > >> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file >> >> Hi Peng, >> >> On Tue, 7 May 2019 at 06:52, Peng Fan wrote: >>> >>> i.MX8 only support AHAB secure boot with Container format image, we >>> could not use FIT to support secure boot, so introduce container >> >> Why not FIT? > > Actually before we implement secure boot, we use FIT image, however > i.MX8 only support i.MX container format image for secure boot, > The chip will verify the container image when secure boot. It could not > recognize > FIT image. So we have to drop FIT image. > >> >>> support to let SPL could load container images. >> >> What is a container image? Can you please point to documentation? > > Sadly, there is no public reference manual. There is a doc that has > a bit of information. https://community.nxp.com/docs/DOC-343178 Shouldn't it suffice for the SPL to be in this custom format , while the rest of the binaries can be in fitImage ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Simon, > Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file > > Hi Peng, > > On Tue, 7 May 2019 at 06:52, Peng Fan wrote: > > > > i.MX8 only support AHAB secure boot with Container format image, we > > could not use FIT to support secure boot, so introduce container > > Why not FIT? Actually before we implement secure boot, we use FIT image, however i.MX8 only support i.MX container format image for secure boot, The chip will verify the container image when secure boot. It could not recognize FIT image. So we have to drop FIT image. > > > support to let SPL could load container images. > > What is a container image? Can you please point to documentation? Sadly, there is no public reference manual. There is a doc that has a bit of information. https://community.nxp.com/docs/DOC-343178 Thanks, Peng. > > > > > Cc: Simon Goldschmidt > > Cc: Tien Fong Chee > > Cc: York Sun > > Cc: Marek Vasut > > Cc: Alex Kiernan > > Cc: Simon Glass > > Cc: Philipp Tomsich > > Cc: Kever Yang > > Cc: Heiko Schocher > > Signed-off-by: Peng Fan > > --- > > common/spl/spl_mmc.c | 10 ++ > > include/spl.h| 12 > > 2 files changed, 22 insertions(+) > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Hi Peng, On Tue, 7 May 2019 at 06:52, Peng Fan wrote: > > i.MX8 only support AHAB secure boot with Container format image, > we could not use FIT to support secure boot, so introduce container Why not FIT? > support to let SPL could load container images. What is a container image? Can you please point to documentation? > > Cc: Simon Goldschmidt > Cc: Tien Fong Chee > Cc: York Sun > Cc: Marek Vasut > Cc: Alex Kiernan > Cc: Simon Glass > Cc: Philipp Tomsich > Cc: Kever Yang > Cc: Heiko Schocher > Signed-off-by: Peng Fan > --- > common/spl/spl_mmc.c | 10 ++ > include/spl.h| 12 > 2 files changed, 22 insertions(+) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
