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
