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

[Marek Vasut]

On 5/21/19 10:32 AM, Lukasz Majewski wrote:
> Hi Peng,
> 
>>> 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.
> 
> Please consider following scenario (I think that this is in sync with
> Marek's point):

It's not in sync, see 2.1 below.

> 1. You wrap SPL into i.MX8 "container", so the SPL would be recognised
> an checked by secure code in ROM.
> 
> 2. Then we do have SPL "trusted". It is up to SPL to:
> 
> 2.1. Use its private key to check u-boot, dtb, etc embedded into
> FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt).

Then you have two private keys, one which is potentially exposed by
being in the SPL. You want to use the crypto engine, which has a key in
it and which cannot be easily extracted.

> 2.2. Use crypto engine (it's API) with fused keys to speed-up the
> process of boot (by HW support to check the binary). Such approach is
> in i.MX6Q.
> 
> 
> By using above approach we do have the NXP's "container" format only
> seen in the SPL (which is OK, as for example Samsung does similar thing
> with FBL/BL1). When SPL is "trused" we may use available facilities.
My question is, how can Linux crypto API make use of the built-in
private key in the iMX8 to authenticate payload ? There surely is a way.

-- 
Best regards,
Marek Vasut