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

[Lukasz Majewski <lukma@denx.de>]

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.  
> > > >
> > > > 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 would check it just out of curiosity.

> i.MX6 HAB secure boot also requires CSF padding
> into image, we could not pass other format image to ROM when using
> HAB, right?
> 

Yes.

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

I just wanted to understand the issue and help to get the simplest
possible solution.

> 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  




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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190522/c0ff8fef/attachment.sig>