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

[Lukasz Majewski]

Hi Marek,

> On 5/21/19 10:32 AM, Lukasz Majewski wrote:
> > 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):  
> 
> It's not in sync, see 2.1 below.
> 
> > 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).  
> 
> Then you have two private keys, 

There shall be s/private key/public key/g in the SPL (but then the
SPL needs to be trusted). 

And I fully agree that we shall use crypto engine whenever possible.

> one which is potentially exposed by
> being in the SPL. You want to use the crypto engine, which has a key
> in it and which cannot be easily extracted.
> 
> > 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.
> > 
> > 
> > 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.  
> My question is, how can Linux crypto API make use of the built-in
> private key in the iMX8 to authenticate payload ? There surely is a
> way.
> 




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/20190521/610d9fa4/attachment.sig>