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

[Bryan O'Donoghue]

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 ?

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.

---
bod