Message-ID:
 <AM9PR04MB8604C2AAA70406883320C5C995FCA@AM9PR04MB8604.eurprd04.prod.outlook.com>
Date: Mon, 27 Oct 2025 06:43:39 +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 v19 0/7] firmware: imx: driver for NXP
 secure-enclave

On 25-09-27, Pankaj Gupta wrote:
>> Highlight:
>>
>> There are long discussion at V18 with Marco Felsch.
>> https://lore.kernel.org/imx/AM9PR04MB8604F5A7DD8B1E41FDAD09039501A@AM9PR04MB
>> 8604.eurprd04.prod.outlook.com/
>>
>> The key point is about using OP-TEE OS.
>>
>> Marco's questions:
>> =================
>> Q1. Both MU(s) from each world - Secure & Non-secure, cannot be used
>>     simultaneously. Why?
>> A1. ELE FW fix is available, where concurrent access to ELE from both the
>>     world is working. This fix is not required for the current patch-set for
>>     i.MX8ULP.
> According https://github.com/OP-TEE/optee_os/pull/7268/commits/83b516edc0270ca8300ce524a0c3d560e67a0f48#r1955899462
> there is no fix yet. Can you please point me to the fixed version?

It is not yet up-streamed to OPTEE-OS repo.
Fix version is part of NXP LF Q3 released on 30 September.
Commit can be found on this URL: https://github.com/nxp-imx/imx-optee-os/commits/lf-6.12.34_2.1.0/.

One more fix is coming in LF Q4. After that, these patches will up-streamed to OP-TEE-OS.
Then you will be able locate it in OPTEE-OS git repo.

Since the current Patch-set is for i.MX8ULP, where concurrent access from both the world is not possible.
In context to i.MX93, for OPTEE-OS patches, request you to please discuss in OPTEE community. Not here.

> Also, can you please outline why the fix is not required for i.MX8ULP?
> Unfortunately I can't remember.
There is no Trust-MU for OPTEE-OS in i.MX8ULP. The ELE driver in OPTEE, is disabled for i.MX8ULP.
Moreover, there is CAAM in i.MX8ULP, which is used for security services, in OPTEE-OS.

>> Q2. How is the secure and non-secure world talk to the ELE if there is only
>>     one MU?
>> A2. From i.MX9x & onwards, SoC(s) has at least one dedicated ELE MU(s) for
>>     each world - Linux(one or more) and OP-TEE OS (one or more). Has updated
>>     the commit message of 3/7.

> Does apply to the i.MX8ULP SoC as well?
No. Since there is no trust-MU for OPTEE-OS, on i.MX8ULP, to communicate with ELE.

> The NXP name scheme isn't very easy to follow.

>> Q3. How exactly do the eFuse write access after the device was locked down,
>>     will be provided with single path; for the following case?
>>     - For a verified boot setup, you need to burn an eFuse at some point,
>>     to tell the bootROM to boot only correct verified firmware images.
>>     - After this lockdown, it's no longer possible to burn eFuses from the
>>     REE, while the production line setup still requires the support.
>> A3. OP-TEE OS supports read fuses, currently as part of our quarterly release.
>>     Write fuse will be in coming release. Please note that the current patch-
>>     set does not contain any read/write eFuse feature.

> But one of your patches is mention it, right? So there will be still two
> paths.
Due to lack of trusted-mu, there is no way to read/write fuse on i.MX8ULP, from OPTEE-OS.
For current patch-set, it is the single path.

> Also according your IOCTL docuementation you want to expose the whole
> device to the user-space?

> | What:          /dev/<se>_mu[0-9]+_ch[0-9]+
> | Date:          Mar 2025
> | KernelVersion: 6.8
> | Contact:       linux-imx@....com, pankaj.gupta@....com
> | Description:
> |                NXP offers multiple hardware IP(s) for secure enclaves like EdgeLock-
> |                Enclave(ELE), SECO. The character device file descriptors
> |                /dev/<se>_mu*_ch* are the interface between userspace NXP's secure-
> |                enclave shared library and the kernel driver.
> |
> |                The ioctl(2)-based ABI is defined and documented in
> |                [include]<linux/firmware/imx/ele_mu_ioctl.h>.
> |                ioctl(s) are used primarily for:
> |                        - shared memory management
> |                        - allocation of I/O buffers
> |                        - getting mu info
> |                        - setting a dev-ctx as receiver to receive all the commands from FW
> |                        - getting SoC info
> |                        - send command and receive command response
                                ^
> This is a rather uncommon approach. The kernel has interfaces to
> abstract hardware. You completely bypass this if you expose everything
> to the userspace.

It is in-correct.
Not everything, just exposed file-operation. and ioctl(s) for DMA(eable) buffer allocation from reserved lower memory region.
Things managed by Kernel:
* Send/receive path to ELE, is managed by Kernel.
* Receive/send patch to the ELE's slave NVM-manager, is managed by kernel.
* Low power management handled by kernel driver. In case of low-power state, ELE driver re-init the V2X IP as part of resume.
* Other kernel management layers like NVMEM, kernel HWRNG, will use the api(s) exposed by this driver.
* Loading the runtime FW.
>
>> Q4. What is the ELE behavior if the secure-world stresses the ELE? Is there
>>     a MU priority so the normal-world MU may get blocked (never addressed)
>>     or are both MUs scheduled in round-robin?
>> A4. ELE will pick the message from Both MU(s), based on FIFO.

> This doesn't answer my question. How gets the FIFO filled? If the one of
> both worlds aways keep the MU busy?

If both the world is keeping the MU busy. ELE will pick the first incoming message, let's say on MU#1,
While acknowledge and queueing the incoming message on the other MU#2, to be picked once
the handling of the current message at hand is completed. Despite the MU#1, is bombarded
With next message, but it will process the message from MU#2, while acking the incoming message
from MU#1. And add it to its queue. This way FIFO is maintained by ELE.

>> Q5. Why ELE performance matters?
>>     - On i.MX8M, which uses the CAAM (the ELE predecessor), It can be
>>     verified that the ARMv8 CE are much faster than the crypto-engine itself.
>>     Therefore the CAAM is mostly unused.
>> A5. User looks for both type of implementation based on their usecase:
>>     - Certain users still offload to CAAM, to save their ARM CPU cycles for
>>     other priority tasks.

> I have never seen such designs but okay.
I assure you, there are several such cases with our system-engineering team.

>>     - While certain customer choose ARM-CE for the crypto offloads for better
>>     performance.
>>     As far as ELE is concerned, it is not a crypto accelerator like CAAM.
>>     Performance hungry crypto-ops are not recommended to be offloaded to ELE.

> I don't get this point. So NXP doesn't recommend to use the ELE for
> crypt-ops?
NXP does not recommend to offload the Crypto-Op to ELE, for performance cases.

>> Q6. For the IOT-cases where real-time encrypted feed from sensors, will take
>>     latency hit, Does the ELE support inline en-/decryption?
>> A6. Yes, ELE support Inline Encryption Engine (IEE), starting i.MX95 onwards.

> May I ask, how is this connected and which interfaces are connected to
> the IEE? I would have checked it by myself but unfortunately NXP doesn't
> provide a TRM for the i.MX95 yet.
We can discuss this in greater depth on one-one email, where I will touch upon the IEE and its interfaces.
But, like to inform that there is not IEE on i.MX8ULP or even on i.Mx93.

>> Marco's Suggestions/NXP response:
>> ================================
>> S1. Below listed ELE access requirements, can be done from OP-TEE OS in all
>>     the Life-Cycle states. then Why to use Linux?
>>     - eFuse access (done via  OP-TEE OS i.MX specific PTA): OTP eFuse R/W access
>>     after doing the LOCK_DOWN fuse is no longer possible without  OP-TEE OS. This
>>     involves general purpose (GP) eFuses too.
>>     - ELE ping every 1 day (kernel SMC WDG driver, OP-TEE OS wd driver).
>>     - HW-RNG (kernel HWRNG driver + OP-TEE OS HWRNG PTA).
>> R1. There are i.MX9* users, that are not using OP-TEE OS, but still want
>>     to use ELE features from Linux. So, these users are requesting for this
>>     driver in Linux.

> Which ELE features?
All the features from Linux, when OPTEE-OS is not present like:
* Read/write efuses. (eg NVMEM Kernel driver). Where there is no requirement to chenge the eFuse, during SoC in provision lifecycle.
* Low power management at Linux driver.
* Linux HWRNG.
* Loading the secondary runtime fw.

>>     As suggested by you, writing to eFuse after life-cycle closed state, the
>>     driver in OP-TEE OS is needed.
>>     Though there are other OP-TEE OS features too, that needs to be offloaded
>>     to HSM, for security reasons, like:
>>     - Hardware Unique Key(HUK) getting generated.
>>     - OP-TEE OS's ASLR seed generation.

> We're talking about features the normal world wants to have access too,
> since you said ".. but still want to use ELE feature from Linux ..". The
> HUK and the TEE ASLR seed is clearly not something Linux wants to have
> access too.
You misunderstood my point. I was stressing that there is a need for two paths,
each from Linux and OPTEE-OS, in order to expose different feature-set required
by respective worlds, where 1 or 2 overlaps, while maximum are utilized by respective
worlds.

>> S2. Having one implementation is beneficial in the following ways:
>>     - Multiple paths also requires more maintain- and testing effort.
>>     - FW files with having +1 FW for the new i.MX9*, where there are plenty
>>       already eg.: bootloader, TF-A, ele-fw, scu-fw (i.MX95), increases the
>>       maintenance on both the paths.
>>     - TEE code could be reused by other OSes.
>>     - TEE is used anyway for new projects due to CRA and friends
>> R2. As conveyed in R1, there are Linux only users, that are dependent on SE
>>     Linux kernel driver.

> What difference does it make if these Linux-only users get the ELE
> access via OP-TEE? It's just one binary more.
If the User does not choose to include optional OPTEE-OS, then ELE access
must be from Linux driver.

>> S3. Having one implementation is beneficial in the following ways:
>>     - Adding the support for it to  OP-TEE OS do not requires ELE-FW.

> I never said that this requires no ELE FW! I said it requires no ELE-FW
> update! Was the update already rolled out?
Yes, the updated FW is already release part of LF Q3 released on September 30, 2025.
It is not released as part any open repo.

>>     - Concurrent access handling is done by the TEE core.
>> R3. As already mentioned that ELE FW fix is available, for concurrent access.
>>     Please note that FW fix is not required for the current patch-set.

> Can you provide us a link to the fix please? The fix should fix the
> concurrent normal-world <-> secure-world MU access issue. Why is this
> fix not required if I have a running OP-TEE?
The fix is very much required to run concurrent access for i.XM93 and onwards.
But not for i.MX8ULP and current patch-set is based on i.MX8ULP.

>> S4. This series causes more confusions till the ELE FW fix is available to
>>     allow concurrent access to ELE from both the worlds.
>> R4. FW fix is already available, and concurrent access is enabled by default
>>     in LF Q3'25, release. Please note that FW fix is not required for the
>>     current patch-set.

> Please provide a link to the new FW and why is the fix nor required for
> this patchset?
Again. The fix is very much required to run concurrent access for i.XM93 and onwards.
But not for i.MX8ULP and current patch-set is based on i.MX8ULP.


>> S5. Suggesting to add the  OP-TEE OS support for the required features e.g. eFuses,
>>     watchdog, HWRNG. The whole Linux part is mostly in place.
>> R5. Yes, the secure world features like eFuse read/write will be added
>>     to OP-TEE OS. Please note that this patch-set does not contain any read/write
>>     eFuse feature.

> I see, instead it expose the whole ELE to the userspace if I got it
> correct according to your IOCTL documentation. This would be even worse.
No, it is not a correct interpretation. As mentioned above, ELE driver abstract
all the hw interaction to have easy and simple file bases operations.

> Regards,
> Marco

Regards,
Pankaj

Powered by blists - more mailing lists