From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Date: Wed, 22 May 2019 04:18:20 +0000 Subject: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file In-Reply-To: <20190521103242.5d57b17f@jawa> References: <20190507130554.4598-1-peng.fan@nxp.com> <20190507130554.4598-5-peng.fan@nxp.com> <10a2f560-a6c1-33d2-ea88-4c4d1894e5f1@gmail.com> <2ab8e478-34e6-edeb-9a2d-519ee4723143@denx.de> <31434bac-e22c-8623-6842-2c923cfbe5f1@denx.de> <4b5f4003-8805-847d-4601-6913c90cef7c@denx.de> <20190521103242.5d57b17f@jawa> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Hi Lukasz, > -----Original Message----- > From: Lukasz Majewski [mailto:lukma at denx.de] > Sent: 2019年5月21日 16:33 > To: Peng Fan > Cc: Marek Vasut ; Marek Vasut ; > Simon Glass ; u-boot at 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 at 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: > lukma at denx.de