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

Wed May 22 07:22:40 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.
> 
> 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.MX6 HAB secure boot also requires CSF padding
into image, we could not pass other format image to ROM when using HAB,
right?

> 
> >
> > >
> > > 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.
> 
> Ok. So it is needed in the ROM "part" of security.
> 
> >
> > 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.
> 
> Ok. So every time we want to use the sc_seco_authenticate API the provided
> image for checking needs to be wrapped into the "container"
> iMX8 specific format.

Yes. Otherwise sc_seco_authenticate will return failure. I could not think
out better solution, another approach is let uboot generating a container header,
and use FIT to wrap the header and other payload images, but I think
directly generating a container image is simpler, because we already have
SPL been wrapped into container format.

Thanks,
Peng.

> 
> >
> > So in vendor tree, uboot/atf/optee are wrapped into a container format
> > image.
> 
> Ok.
> 
> >
> > >
> > > 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
> 
> 
> 
> 
> 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