[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
Peng Fan
peng.fan at nxp.com
Wed Jun 5 03:03:33 UTC 2019
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> container format file
>
> On 6/5/19 3:59 AM, Peng Fan wrote:
> >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading
> >> i.MX container format file
> >>
> >> On 6/5/19 3:18 AM, Peng Fan wrote:
> >>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> >>>> loading i.MX container format file
> >>>>
> >>>> 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.
> >>>
> >>> The change to spl mmc common code is as below:
> >>> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index
> >>> bf53a1dadf..6320af055b 100644
> >>> --- a/common/spl/spl_mmc.c
> >>> +++ b/common/spl/spl_mmc.c
> >>> @@ -79,6 +79,16 @@ int mmc_load_image_raw_sector(struct
> >> spl_image_info *spl_image,
> >>> load.bl_len = mmc->read_bl_len;
> >>> load.read = h_spl_load_read;
> >>> ret = spl_load_simple_fit(spl_image, &load, sector,
> >>> header);
> >>> + } else if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
> >>> + struct spl_load_info load;
> >>> +
> >>> + load.dev = mmc;
> >>> + load.priv = NULL;
> >>> + load.filename = NULL;
> >>> + load.bl_len = mmc->read_bl_len;
> >>> + load.read = h_spl_load_read;
> >>> +
> >>> + ret = spl_load_imx_container(spl_image, &load,
> >>> + sector);
> >>> } else {
> >>>
> >>> If IMX_CONTAINER is not preferred
> >>
> >> I never implied that.
> >>
> >>> , I'll change it to CONFIG_SPL_LOAD_VENDOR_FORMAT.
> >>> In this way, only i.MX users need to take care container format, non
> >>> i.MX users no need to care about that.
> >>
> >> That would make it even worse, since if we follow this course of
> >> development, I suspect iMX9 will have another different container
> >> format and the list will grow on.
> >
> > Let me summary the previous SoC that NXP is actively maintaining
> > i.MX6/7/7ULP/8M use IVT i.MX8/8X use container
> >
> > I could not disclose information about future i.MX SoC.
>
> My assumption is that the future iMX SoC will use yet another different
> container format.
>
> >>> It is not duplication of FIT. Container support the similar function
> >>> of FIT image, but it is not only that.
> >>
> >> So what is it ?
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da
> ta=02%7C
> >
> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
> 86ea1d3b
> >
> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&sdat
> a=KO%2B0e
> >
> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&reserv
> ed=0
> > Chapter 5 has information about container set and container.
>
> Thanks, any specific part of those 80 pages ?
Figure 5-24. Container Format has a picture about a single container.
i.MX8 container also support container sets, support encrypt blob,
certificates, SRK management. Support signature to the whole container,
no need single image inside container.
>
> >> I don't think I get it. Why would I, as an iMX8 user, want to pick
> >> custom new vendor-specific format over years-proven generic fitImage?
> >
> > We not against FIT, we already use FIT on i.MX8M, to let spl to
> > authenticate FIT image using ROM HAB, not using crypto driver.
>
> Great
>
> >> What is the selling point here ?
> >
> > We would not introduce cypto driver in SPL stage, that means HAB FIT
> > and AHAB container needs to be dropped when SPL loading other images.
> > ROM already provides API for bootloader to authenticate images,
> > introducing complex crypto driver in SPL could enlarge code size and
> > make things complicated.
>
> Ah I see, so it's all making the whole crypto simpler by offloading the hard
> parts into the firmware, which just magically handles everything , without
> having much extra code in the SPL ?
Yes. Use what ROM provides will make things easier for U-Boot.
Thanks,
Peng.
>
> --
> Best regards,
> Marek Vasut
More information about the U-Boot
mailing list