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 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. Ok. So it is needed in the ROM "part" of security. > > 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 the container header/image. Ok. So every time we want to use the sc_seco_authenticate API the provided image for checking needs to be wrapped into the "container" iMX8 specific format. > > So in vendor tree, uboot/atf/optee are wrapped into a container > format image. Ok. > > > > > In which other cases the container image is needed in U-Boot proper > > or Linux kernel? > > When uboot authenticate kernel, we also wrap kernel image into a > container format file using CST. I do not know how Linux kernel > itself authenticate others. > > Thanks, > Peng. > > > > > > > > > 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 > > > > > > > > > > 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 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
pgplpd1Dwp1Ds.pgp
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
