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