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

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 06/04/2019 22:41, Breno Matheus Lima wrote:
> 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:
>> 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.

I don't understand that comment, perhaps you can give an example.

> 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?

TBH, I see that as something that should be done _anyway_ not instead 
i.e. after u-boot, if you want to do 'stuff' with the CAAM you are either

1. Running in non-secure Linux, in which case you need the job-rings
    assigned to non-secure mode or

2. You are running inside of a TEE, in which case you absolutely need
    to have at least one job-ring

... and for the second case the right thing to do is to arbitrate 
ownership of job-rings via a DTB

> 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.

But if u-boot is running in secure-world

save_jr_context();
setup_some_new_jr_context();
hab_authenticate_something();
restore_jr_context();

As a "quick fix", that's the way I'd do it. Just pivoting on 
CONFIG_OPTEE is pretty easy to break i.e. you can have CONFIG_OPTEE 
defined in your u-boot config but not actually be executing a TEE, in 
which case by the time you boot Linux your JR assignment is wrong..

The correct and flexible fix is passing a DTB descriptor that u-boot, 
OPTEE and Kernel can put data into so that there's a canonical 
description of which execution environment owns what.

---
bod