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
