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

Peng Fan peng.fan at nxp.com
Wed May 22 04:18:20 UTC 2019


Hi Lukasz,

> -----Original Message-----
> From: Lukasz Majewski [mailto:lukma at denx.de]
> Sent: 2019年5月21日 16:33
> To: Peng Fan <peng.fan at nxp.com>
> Cc: Marek Vasut <marex at denx.de>; Marek Vasut <marek.vasut at gmail.com>;
> Simon Glass <sjg at chromium.org>; u-boot at lists.denx.de; Tien Fong Chee
> <tien.fong.chee at intel.com>; York Sun <york.sun at nxp.com>; dl-uboot-imx
> <uboot-imx at nxp.com>
> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
> format file
> 
> Hi Peng,
> 
> > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> > > container format file
> > >
> > > On 5/21/19 4:55 AM, Peng Fan wrote:
> > > [...]
> > >
> > > >>>>> I do not know how other SoC vendor did FIT hardware secure
> > > >>>>> boot, please share you have any information.
> > > >>>>
> > > >>>> The SPL can be in the custom format, but then can load fitImage
> > > >>>> with the next stage(s), right ?
> > > >>>
> > > >>> I am not able to follow you, could you share more details?
> > > >>
> > > >> Wrap the SPL into this custom format and then have the SPL
> > > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB
> > > >> etc). Would that work ?
> > > >
> > > > It not work.
> > > > We already wrap SPL in i.MX container format, this patchset is to
> > > > let SPL could load the 2nd container file which contains
> > > > U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which
> > > > contains (U-Boot/DTB and etc), it could not pass secure boot
> > > > authentication, because ROM not know fitimage, it only know i.MX
> > > > container format.
> > >
> > > It's not bootrom that authenticates the next stage, it's U-Boot SPL.
> > > BootROM already authenticated and started the U-Boot SPL, so that's
> > > a trusted code. Now this trusted code can authenticate and start the
> > > next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already out
> > > of the picture at this point.
> >
> > Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API
> > for others to use, sc_seco_authenticate is the API that used for
> > authentication. I could not share more information about this API
> > works inside SCFW and ROM. sc_err_t sc_seco_authenticate(sc_ipc_t ipc,
> > sc_seco_auth_cmd_t cmd, sc_faddr_t addr)
> >
> > SPL will call this API, one parameter is address which needs a
> > container image there.
> 
> Please consider following scenario (I think that this is in sync with Marek's
> point):
> 
> 1. You wrap SPL into i.MX8 "container", so the SPL would be recognised an
> checked by secure code in ROM.
> 
> 2. Then we do have SPL "trusted". It is up to SPL to:
> 
> 2.1. Use its private key to check u-boot, dtb, etc embedded into FitImage (as
> written here: ./doc/uImage.FIT/verified-boot.txt).
> 
> 2.2. Use crypto engine (it's API) with fused keys to speed-up the process of
> boot (by HW support to check the binary). Such approach is in i.MX6Q.

I suppose you talking HAB.

> 
> 
> 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.

If I switch to FIT, I need to use FIT to wrap a container image, it does not
make sense to me.

Thanks,
Peng.
> 
> >
> > >
> > > > For authentication, we always let ROM to authenticate including
> > > > SPL authenticating U-Boot, so we need pass an image to ROM that
> > > > ROM could recognize when SPL booting 2nd image.
> > >
> > > Shouldn't the CPU have some sort of facility, like a crypto engine,
> > > which authenticates whatever blob with the right signature against a
> > > key burned into the CPU ? If so, then you would just implement a
> > > crypto driver and pass the blob and signature to it. I suspect
> > > that's how it should work, how else would Linux be able to make use
> > > of these secure bits if it cannot call the bootrom anymore ?
> >
> > sc_seco_authenticate on i.MX8 will always be available. It is exported
> > by a runtime firmware running on a Cortex-M core inside i.MX8. The API
> > will do authentication, its accepts container format image as input
> > and no other format.
> >
> > Thanks,
> > Peng.
> >
> > >
> > > --
> > > Best regards,
> > > Marek Vasut
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma at denx.de


More information about the U-Boot mailing list