Message-ID: <087b8689-7443-4720-a94c-160edd31a5da@kontron.de>
Date: Tue, 1 Jul 2025 12:44:52 +0200
From: Frieder Schrempf <frieder.schrempf@...tron.de>
To: Marco Felsch <m.felsch@...gutronix.de>
Cc: Pankaj Gupta <pankaj.gupta@....com>, 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

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.

> 
>  - 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.

> 
>  - 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.
> 
> 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.

> 
>> 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.

Powered by blists - more mailing lists