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

[Bryan O'Donoghue]

On 07/04/2019 19:56, Breno Matheus Lima wrote:
> Hi Bryan,
> 
> Em dom, 7 de abr de 2019 às 05:05, Bryan O'Donoghue
> <bryan.odonoghue at linaro.org> escreveu:
>>
>>
>>
>> On 06/04/2019 22:41, Breno Matheus Lima wrote:
>> save_jr_context();
>> setup_some_new_jr_context();
>> hab_authenticate_something();
>> restore_jr_context();
> 
> This can only work if we do similar operation in CMD_DEKBLOB:
> 
> save_jr_context();
> setup_some_new_jr_context();
> blob_dek()
> restore_jr_context();
> 
> Both operations blob_dek() and hab_authenticate_image() at U-Boot
> level must have the Job Ring assigned for TrustZone secure world. The
> first authentication/decryption at bootROM level is expecting a DEK
> blobs generated by TrustZone secure world.

Ah right, yes good point, I wasn't entirely following you on the DEK bit 
of it.

Yes we would need to save and restore context for both cases i.e. any 
time we call into the BootROM and the BootROM wants to perform CAAM 
operations as a result.

>> 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..
> 
> Can you please provide more details on how this can break users that
> has CONFIG_OPTEE defined and are not executing a TEE? 

My point here is you can't presuppose how a boot flow will work simply 
due to a CONFIG option.

And indeed if you run an NXP TEE with a CAAM driver you still have the 
problem that the initial jr ownership defined by u-boot is now wrong by 
the time the kernel runs.

> From my
> understanding Linux Kernel will be running in TZ secure world and JRs
> assigned to TZ non-secure world, CAAM driver can still be used on this
> condition (Similar as we currently have for mx7dsabresd target).

Linux will be running in _normal_ world. A TEE will be running in secure 
world.

Then again a TEE might not be involved.

As soon as you guys want to land your CAAM driver in upstream OP-TEE I 
think a conversation needs to be had re: assignment of job-ring ownership.

Basically if your TEE wants a CAAM job-ring, that's fine but, that 
allocation needs to be stuffed into a DTB the kernel can access.


> In order to have a quick fix available, what about delaying the Job
> Ring assignment in U-Boot?
> 
> Perhaps we can provide an U-Boot command to set the Job Ring
> ownership, users can add this command in their boot script just before
> booting Kernel and/or OP-TEE.

Technically it could work but, how is it a better solution to have all 
users of the CAAM have to modify their boot flow, than put a context 
save/restore wrapper into hab_auth() and blob_dek() that hides the detail ?

> 
>>
>> 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.
>>
> 
> Yes, I agree. We need a more flexible fix here.

DTB is the way to go.