From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Date: Tue, 21 May 2019 03:19:38 +0000 Subject: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file In-Reply-To: <4b5f4003-8805-847d-4601-6913c90cef7c@denx.de> 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> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > 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