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

[Marek Vasut]

On 6/4/19 5:27 AM, Peng Fan wrote:
>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>> container format file
>>
>> On 5/30/19 9:06 AM, Ye Li wrote:
>>> 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.
>>
>> So can we put a public key into the SPL and use it to verify a fitImage ?
> 
> Technically doable. But compared with the current approach that reuse
> ROM public API, Using crypto driver in SPL will be complicated and code
> size larger without calling ROM API.
> 
> I do not understand the problem the SPL loading NXP i.MX8 container format.
> SPL should only support raw and fit format? vendor format is not
> allowed and not accepted?

The problem I have is with the duplication of functionality -- the iMX8
custom format does exactly the same as fitImage, except differently and
with smaller user base, thus with less users and reviewers and thus with
less potential bugfixes, which I think in crypto code is important.

-- 
Best regards,
Marek Vasut