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

Wed May 22 06:15:06 UTC 2019

> > > > > 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.
> 
> Yes. As described here:
> 
> https://www.nxp.com/docs/en/application-note/AN4581.pdf
> 
> >
> > >
> > >
> > > 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.

> 
> Or is it just the function executed by ROM on the very beginning to load SPL?
> 
> >
> > If I switch to FIT, I need to use FIT to wrap a container image, it
> > does not make sense to me.
> 
> Please correct me if I'm wrong, but isn't the container image only needed to
> wrap SPL?

Container image will wrap SPL to make ROM could load SPL, Kick SPL and
authenticate SPL.

When SPL booting U-Boot, SPL could use FIT to load and boot uboot.
But when SPL need to authenticate U-Boot with AHAB on i.MX8, a container
format header/image needs to be passed to sc_seco_authenticate API, the API
internal implementation is it will parse the container header/image.

So in vendor tree, uboot/atf/optee are wrapped into a container format image.

> 
> In which other cases the container image is needed in U-Boot proper or Linux
> kernel?

When uboot authenticate kernel, we also wrap kernel image into a container format
file using CST. I do not know how Linux kernel itself authenticate others.

Thanks,
Peng.

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