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 ?