[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut <marex@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