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