[EXT] Re: [PATCH v18 3/7] firmware: imx: add driver for NXP EdgeLock Enclave
Pankaj Gupta
pankaj.gupta at nxp.com
Fri Jun 27 00:11:13 PDT 2025
>> 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 at nxp.com>
> Reviewed-by: Frank Li <Frank.Li at nxp.com>
>
> ---
> Changes from v17 to v18
> - Collected Frank's R-b tag.
> ---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 11094 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250627/f1e6f5ea/attachment.p7s>
More information about the linux-arm-kernel
mailing list