[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file
Peng Fan
peng.fan at nxp.com
Tue May 21 03:19:38 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.
>
> > 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
More information about the U-Boot
mailing list