Hi Bryan,
Em dom, 7 de abr de 2019 às 05:05, Bryan O'Donoghue bryan.odonoghue@linaro.org escreveu:
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.
You can take a look in application note AN12056: https://www.nxp.com/docs/en/application-note/AN12056.pdf
Section 2.2 provides more details on the encrypted boot sequence, as you can see in Figure 1 the U-Boot image is decrypted at bootROM level after a system reset. Section 4 explains how to encrypt and sign an U-Boot image.
As I mentioned in commit log, the ROM code expects DEK blobs encapsulated by the Secure World environments which commonly have JROWN_NS = 0.
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
Running in non-secure Linux, in which case you need the job-rings assigned to non-secure mode or
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/ca...
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();
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.
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? 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).
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.
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.
Best regards, Breno Lima