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.odonog...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
