>> Add driver for enabling MU based communication interface to secure-enclave. >> >> NXP hardware IP(s) for secure-enclaves like Edgelock Enclave(ELE), are >> embedded in the SoC to support the features like HSM, SHE & V2X, using >> message based communication interface. >> >> The secure enclave FW communicates with Linux over single or multiple >> dedicated messaging unit(MU) based interface(s). >> Exists on i.MX SoC(s) like i.MX8ULP, i.MX93, i.MX95 etc. > You write single or multiple MUs are possible. I'm aware that the i.MX93 has two MUs one for the secure and one for the non-secure world. But I'm really concerned about the fact that both MUs can't be used at the same time from both world: Yes, you are correct. > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com %2FOP-TEE%2Foptee_os%2Fpull%2F7268%2Fcommits%2F83b516edc0270ca8300ce524a0c3d 560e67a0f48%23r1955899462&data=05%7C02%7Cpankaj.gupta%40nxp.com%7C9c89533065 c94aa6235308ddb3d6dfd4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63886445 7643839807%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=U%2Ff GBCg6g7dXcbG3R59SmKMdBdoZmbQ%2BiKYaGl5mLm0%3D&reserved=0 Fix is still work in progress. > Also how is the secure and non-secure world talking to the ELE if there is only one MU as you have written? Till the fix is WIP, either Linux or OPTEE can use the ELE, at one point in time. > IMHO it makes much more sense to put the complete ELE communication into (OP-)TEE and let the secure OS taking care of it. All non-secure world requests are passed via (OP-)TEE to the ELE. This involves: > - eFuse access (done via OP-TEE i.MX specific PTA) > - ELE 23h59m ping (kernel SMC WDG driver, requires OP-TEE watchdog driver) > - HW-RNG (kernel OP-TEE HWRNG driver + OP-TEE HWRNG PTA) There is a dedicated MU "trusted-MU" for OPTEE-OS. The idea to converge to a single path via OPTEE-OS, is good. But it will impact the performance of the features at Linux side. Since the fix is still WIP. Let's wait till then. > Regards, > Marco > Other dependent kernel drivers will be: > - NVMEM: that supports non-volatile devices like EFUSES, > managed by NXP's secure-enclave. > > Signed-off-by: Pankaj Gupta <pankaj.gupta@xxxxxxx> > Reviewed-by: Frank Li <Frank.Li@xxxxxxx> > > --- > Changes from v17 to v18 > - Collected Frank's R-b tag. > ---
Attachment:
smime.p7s
Description: S/MIME cryptographic signature