[EXT] Re: [PATCH v18 3/7] firmware: imx: add driver for NXP EdgeLock Enclave

[Pankaj Gupta]

> Am 30.06.25 um 14:17 schrieb Marco Felsch:
>> Hi Frieder,
>>
>> On 25-06-30, Frieder Schrempf wrote:
>>> Hi Marco,
>>>
>>> Am 27.06.25 um 10:46 schrieb Marco Felsch:
>>>> Hi,
>>>>
>>>> your e-mail configuration mixed my e-mail with your answer, which 
>>>> makes it hard to read. Can you please check the quoting next time :)
>>>>
>>>> On 25-06-27, Pankaj Gupta wrote:
>>>>>>> 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.
>>>>>
>>>>> Fix is still work in progress.
>>>>
.>>> So after ~6 months no fix is available :(
>>>>
>>>>>> 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.
>>>>
>>>> That has nothing to do with the fix. The fix is for platforms/SoCs 
>>>> which do have 2-MUs, but you also have written that there are 
>>>> platforms with only 1-MU.
>>>>
>>>> This MU can't be shared between secure and non-secure world.
>>>>
>>>>>> 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
>>>>
>>>> Yes for systems with 2-MUs there is a "trusted-MU" and a 
>>>> "non-trusted-MU". As of now, there is no fix available for using 
>>>> both MUs at the same time. Furhtermore there are platforms/SoCs with 
>>>> only 1-MU, as you have written in your commit message. This 1-MU 
>>>> system can have the MU either trusted or non-trusted.
>>>>
>>>>> single path via OPTEE-OS, is good. But it will impact the 
>>>>> performance of the features at Linux side.
>>>>
>>>> Performance? We are talking about a ping every 23h59m (I still don't 
>>>> know if this is a feature or bug), eFuse write/read, and the HW-RNG 
>>>> which can seed the Linux PRNG.
>>>>
>>>>> Since the fix is still WIP. Let's wait till then.
>>>>
>>>> The fix is for the 2-MUs SoCs but not the 1-MU case.
>>>>
>>>> I would like to have a system design which doesn't differ too much 
>>>> between SoCs which are equipped with the ELE engine.
>>>
>>> Do we really want to depend on OP-TEE to be available for having 
>>> things like OTP fuse access and HWRNG? Personally I'd like to be able 
>>> to build systems with OTP access and HWRNG but without OP-TEE. 
>>> Requiring OP-TEE only to make the ELE available to the kernel in 
>>> cases where the secure world isn't used for anything else seems to be
unnecessarily complex.
>>
>> I understand your point. I don't like pulling in more FW neither but 
>> we need to the face the following facts:
>>
>>  - OTP eFuse R/W access after doing the LOCK_DOWN fuse is no longer
>>    possible without OP-TEE. This involves general purpose (GP) eFuses
>>    too. We faced this limitation in a current project.

> Ok, interesting. Where do find information about the LOCK_DOWN fuse? I
don't see it mentioned in the (Security) Reference Manual of the i.MX93.

>From i.MX9x & onwards, SoC(s) has at least one dedicated ELE MU(s) for each
world - Linux(one or more) and OPTEE-OS (one or more).
As mentioned earlier, the fix for the issue of using OPTEE-OS dedicated MU
on i.MX93, is identified & under testing.

Other point on whether OTP effuse are R/W access, after LOCK_DOWN fuse?
Not sure about how "doing the LOCK_DOWN fuse"?
Please elaborate more on this.

>>
>>  - With new regulations like the EU CRA I think we need some sort of
>>    secure-enclave anyway.

> Probably some sort of, yes. But not necessarily in the form of TEE or
TrustZone, I guess.
To use ELE features through Linux, there is no dependency on OPTEE-OS.

>>
>>  - Making it optional cause more paths of potential errors e.g. by not
>>    including the correct "secure.dtsi". Multiple paths also require more
>>    maintain- and testing effort. IMHO I do think that one of the paths
>>    get unmaintened at some point but we would need to keep it for
>>    backward compatibility.
>>
>>    Having one implementation eliminates this since.
>>
>>  - All above points assume that the ELE-FW and -HW is capable of talking
>>    to both world, which is not the case. As we learned NXP doesn't have
>>    a fix for the 2-MUs ELE yet and even more important there are 1-MU
>>    ELE-IPs.
For i.MX9x SoC(s) there is at least one dedicated ELE MU(s) for each world -
Linux(one or more) and OPTEE-OS (one or more), that needs to be shared
between them.
As mentioned earlier, there is an issue of using MUs simultaneously, from
both worlds. Fix is in progress.

>>
>> I do see the (minimal) drawback of having +1 FW but I think this is 
>> more an integration problem.
>> Speaking of FW files, for the new i.MX9* you already have plenty fo
>> them: bootloader, TF-A, ele-fw, scu-fw (i.MX95). So your integation 
>> needs to handle multiple firmware files already.

> Sure, but I really like to keep the complexity and therefore the number of
FW files as low as possible. I'm not sure what has more weight in terms of
security: shipping an additional firmware and therefore increasing the
attack surface or maintaining an additional code-path.

There is no +1 firmware in case of i.MX93.

>>
>>> Anyway, I see your point of having a single implementation for the 
>>> ELE API in the "right" place. But as far as I know other platforms 
>>> like
>>> STM32MP1 also implement both ways for the HWRNG, secure access via 
>>> OPTEE and non-secure access via kernel directly.
>>
>> I'm not a STM32MP1 expert but here you have this setup with the 
>> *-scmi.dtsi. So you have two code paths which needs to be maintained 
>> and tested. Also if one customer of yours want to use OP-TEE you need 
>> the integration anyway, so you (Kontron) needs to maintain multiple 
>> configuration as well. I don't see the added value.
>>
>> I think for STM32MP1 the *-scmi.dtsi support was added later because 
>> it required a lot effort to support it. This is not the case for the 
>> i.MX9* series.

> Anyway, thanks for elaborating. Your points are all valid and basically I
agree. I'm fine with either way. But I'm afraid that implementing the ELE
API in OP-TEE only will cause another tremendous delay for having ELE access
in the kernel, especially seeing how slow NXP seems to be working on these
topics right now.

To use ELE features through Linux, there is no dependency on OPTEE-OS.
-------------- 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/20250709/4697b8fd/attachment.p7s>