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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
