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

[Marek Vasut]

On 5/27/19 11:49 AM, Peng Fan wrote:
> Hi Marek, Lukasz,
> 
>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>> container format file
>>
>> Hi Marek,
>>
>> On 2019/5/22 19:41, Marek Vasut wrote:
>>> Caution: EXT Email
>>>
>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
>>> [...]
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> The issue to me is that sc_seco_authenticate could not take a
>>>>>>>>> FIT image as input.
>>>>>>>>
>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL, U-Boot
>>>>>>>> proper or Linux crypro engine driver?
>>>>>>>
>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not know
>>>>>>> about Linux crypto driver.
>>>>>>
>>>>>> Maybe it would be worth to check how Linux handle this? Maybe it
>>>>>> would shed some more light on it?
>>>>>
>>>>> I am not familiar with that, so might be stupid question below.
>>>>> Does it really matter?
>>>>
>>>> I would check it just out of curiosity.
>>>
>>> Yes, it matters, because there should be such API. How would Linux
>>> authenticate e.g. userspace binaries if there wasn't one, surely not
>>> by wrapping every single object into the custom vendor-specific container ?
>>> And if there is one, you can use it to authenticate raw binaries from
>>> U-Boot SPL too, e.g. fitImage blobs with an associated signature.
>>>
>>
>> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called
>> SRK is a array of public key hash which is dedicated for AHAB. It is not a real
>> key. The real public key is in container.
>> AHAB will check the public key with the on-chip SRK before using it to
>> authenticate the image.
>> Seco which contains the crypto engine on imx8 does not allow to use the SRK
>> by user. No such API exported.
>> And the fuse of SRK is locked, can't be read directly.
>>
>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM
>> HAB to implement the trust chain, like SPL authenticates u-boot, u-boot
>> authenticatse kernel. We just follow this same way on imx8, the difference is
>> imx8 needs container format for signed image. We prefer directly loading
>> container image than fit image.
>> If we pack fit image into container, obviously this will cause one more copy.
>> As a boot loader, isn't it better to have more image format supported?

If the functionality of the new image format is a subset of already
present image format, then no, that's called a duplication.

>> We
>> don't force to use container, just set it as default. Users still can choose fit or
>> raw image.

They can. however they cannot authenticate the fitImage because the
firmware doesn't provide the necessary API for that ?

> 
> Do you have more comment?

How could Linux use this iMX8 chain of trust stuff to authenticate e.g.
userspace binaries ? It's the same thing as authenticating blob in a
fitImage.

-- 
Best regards,
Marek Vasut