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
