From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Mon, 27 May 2019 13:31:53 +0200 Subject: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file In-Reply-To: References: <20190507130554.4598-1-peng.fan@nxp.com> <31434bac-e22c-8623-6842-2c923cfbe5f1@denx.de> <4b5f4003-8805-847d-4601-6913c90cef7c@denx.de> <20190521103242.5d57b17f@jawa> <20190522080252.732e5b20@jawa> <20190522084622.7d63c32d@jawa> <20190522093407.4b941de6@jawa> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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