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