From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bryan O'Donoghue Date: Sun, 7 Apr 2019 09:05:47 +0100 Subject: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent In-Reply-To: References: <1554480925-36-1-git-send-email-breno.lima@nxp.com> <479d5fa5-e9dd-f45b-5db6-45b6bfdde791@linaro.org> Message-ID: <8e7b74c9-0399-c514-7f34-b61a2c6b5537@linaro.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 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 > 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