[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<AM9PR04MB8604611B8D91B5526C9704E69545A@AM9PR04MB8604.eurprd04.prod.outlook.com>
Date: Fri, 27 Jun 2025 07:11:13 +0000
From: Pankaj Gupta <pankaj.gupta@....com>
To: Marco Felsch <m.felsch@...gutronix.de>
CC: Jonathan Corbet <corbet@....net>, Rob Herring <robh@...nel.org>, Krzysztof
Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Shawn Guo
<shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix
Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>, "linux-doc@...r.kernel.org"
<linux-doc@...r.kernel.org>, Frank Li <frank.li@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [EXT] Re: [PATCH v18 3/7] firmware: imx: add driver for NXP
EdgeLock Enclave
>> 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@....com>
> Reviewed-by: Frank Li <Frank.Li@....com>
>
> ---
> Changes from v17 to v18
> - Collected Frank's R-b tag.
> ---
Download attachment "smime.p7s" of type "application/pkcs7-signature" (11094 bytes)
Powered by blists - more mailing lists