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.
- You wrap SPL into i.MX8 "container", so the SPL would be
recognised an checked by secure code in ROM.
- 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@denx.de