[U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent

[Breno Matheus Lima <brenomatheus@gmail.com>]

Hi Bryan,

Em sáb, 6 de abr de 2019 às 12:21, Bryan O'Donoghue
<bryan.odonoghue@linaro.org> escreveu:
>
>
>
> On 05/04/2019 17:16, Breno Matheus Lima wrote:
> > +     if ((IS_ENABLED(CONFIG_OPTEE) ||
> > +          !IS_ENABLED(CONFIG_ARMV7_BOOT_SEC_DEFAULT)) &&
> > +          !IS_ENABLED(CONFIG_CMD_DEKBLOB)) {
>
> So.
>
> How does this patch work if you want to do HABv4 encrypted
> authentication of an OP-TEE image prior to booting it ?

Thanks for your comments and for pointing this out, I agree that this
can be an issue for OP-TEE users that may want to decrypt additional
boot images at U-Boot level.

The main issue is that all users are currently impacted in first
authentication/decryption executed at BootROM level:

BootROM -> HABv4 -> U-Boot

We may need to come up with a solution suitable for all use cases.

>
> i.e.
>
> You'll switch the job-ring ownership over to non-trusted world, call HAB
> and the BootROM will fail to authenticate.
>
> How about we improve the hab driver in u-boot ?
>
> 1. I notice somebody has already added a save_gd()/restore_gd() pair
> 2. How about a save_jr()/restore_jr() pair and
> 3. a bootrom_jr_setup() ?
>
> In pseudocode then
>
> do_hab_auth()
> {
>         save_jr();              // save current job-ring context
>         bootrom_jr_setup();     // set job-ring to bootrom mode
>         hab_rvt_authenticate();
>         restore_jr();           // restore previous job-ring context
> }
>
> That gets us out of the nasty business of
>
> 1. Constraining the use case of CONFIG_OPTEE=y &&
>     authenticate(encrypted-dek-blob);
>
> 2. Pushing changes into upstream OP-TEE for job-ring assignment
>
> IMV - we should save and restore the job ring context so that all of
> this stuff will "just work"
>
> That should work for
>
> BootROM -> u-boot -> HABv4 auth(encryptedblob) -> Linux
>
> and
>
> BootROM -> u-boot -> run optee -> HABv4 auth(encrypted blob) -> Linux
>
> Basically you've described and additional dependency the BootROM has, so
> lets just "switch context" prior to calling into the BootROM and restore
> to a default non-secure job-ring assignment after.

Yes, this can work for OP-TEE users decrypting additional boot images
at U-Boot level, however all users won't be able to
authenticate/decrypt the initial boot image at BootROM level. Out of
reset CAAM job rings are assigned to TrustZone secure world and
BootROM code is expecting blobs generated by the same environment.

What about moving the job rings assignment to OP-TEE level? Something
similar as we currently have in imx-optee-os project?

https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/drivers/caam/hal/imx_6_7/hal_jr.c?h=imx_4.14.78_1.0.0_ga#n31

U-Boot is running in TrustZone secure world in most of targets, in my
opinion it makes sense to have at least 1 job ring assigned to
TrustZone secure world.

Best regards,
Breno Lima