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 ?

-- 
Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to