-----Original Message----- From: Bryan O'Donoghue [mailto:bryan.odonoghue@linaro.org] Sent: Friday, January 26, 2018 5:55 PM To: u-boot@lists.denx.de; trini@konsulko.com Cc: Peng Fan peng.fan@nxp.com; Fabio Estevam fabio.estevam@nxp.com; lukas.auer@aisec.fraunhofer.de; Bryan O'Donoghue bryan.odonoghue@linaro.org; Alexandru Porosanu alexandru.porosanu@nxp.com; Ruchika Gupta ruchika.gupta@nxp.com; Aneesh Bansal aneesh.bansal@nxp.com Subject: [RESEND PATCH v3 1/2] drivers/crypto/fsl: assign job-rings to non- TrustZone
After enabling TrustZone various parts of the CAAM silicon become inaccessible to non TrustZone contexts. The job-ring registers are designed to allow non TrustZone contexts like Linux to still submit jobs to CAAM even after TrustZone has been enabled.
The default job-ring permissions after the BootROM look like this for job-ring zero.
ms=0x00008001 ls=0x00008001
The MS field is JRaMIDR_MS (job ring MID most significant).
Referring to "Security Reference Manual for i.MX 7Dual and 7Solo Applications Processors, Rev. 0, 03/2017" section 8.10.4 we see that JROWN_NS controls whether or not a job-ring is accessible from non TrustZone.
Bit 15 (TrustZone) is the logical inverse of bit 3 hence the above value of 0x8001 shows that JROWN_NS=0 and TrustZone=1.
Clearly then as soon as TrustZone becomes active the job-ring registers are no longer accessible from Linux, which is not what we want.
This patch explicitly sets all job-ring registers to JROWN_NS=1 (non TrustZone) by default and to the Non-Secure MID 001. Both settings are required to successfully assign a job-ring to non-secure mode. If a piece of TrustZone firmware requires ownership of job-ring registers it can unset the JROWN_NS bit itself.
This patch in conjunction with a modification of the Linux kernel to skip HWRNG initialisation makes CAAM usable to Linux with TrustZone enabled.
Signed-off-by: Bryan O'Donoghue bryan.odonoghue@linaro.org Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Alex Porosanu alexandru.porosanu@nxp.com Cc: Ruchika Gupta ruchika.gupta@nxp.com Cc: Aneesh Bansal aneesh.bansal@nxp.com Link: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c om%2FOP- TEE%2Foptee_os%2Fissues%2F1408&data=02%7C01%7Cruchika.gupta%40nxp.c om%7C1fe21d0a12d34d7722c008d564b7cb4d%7C686ea1d3bc2b4c6fa92cd99c5 c301635%7C0%7C0%7C636525662918265016&sdata=Nt5Fu2LYXDq95Rlv7N5Ns w45tO%2Fw3nDcbQF%2BOPRP7PI%3D&reserved=0 Link: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.c om%2Fyam5gv9a&data=02%7C01%7Cruchika.gupta%40nxp.com%7C1fe21d0a12 d34d7722c008d564b7cb4d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1 %7C636525662918265016&sdata=BypstfduS%2FVyPaeEQCj1hyx5RRSF690SbLaxZ j74KPo%3D&reserved=0 Tested-by: Lukas Auer lukas.auer@aisec.fraunhofer.de
Reviewed-by: Ruchika Gupta ruchika.gupta@nxp.com