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

[Ye Li]

On 2019/5/27 19:31, Marek Vasut wrote:
> Caution: EXT Email
> 
> 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.
> 

Userspace binaries don't use the same key pair. They are signed by software vendors' key. The private 
key for chip secure boot is only hold by device manufacturer.
For example, android needs to authenticate a signed APK. Its public key (Key A) is in system FS. 
iMX trust chain only reaches to kernel + ramdisk. Then the chain hands over to android. 
In ramdisk, android puts another public Key (Key B) used by dm-verify for system FS. So once 
system FS is verified ok, then the public key A becomes trusted. Finally we can use public key A for 
APK authentication.


Best regards,
Ye Li

> --
> Best regards,
> Marek Vasut
>