Message-ID: <b02055bb-0995-4fd8-99f3-4ca5146eedd4@kontron.de>
Date: Mon, 30 Jun 2025 12:32:30 +0200
From: Frieder Schrempf <frieder.schrempf@...tron.de>
To: Marco Felsch <m.felsch@...gutronix.de>,
 Pankaj Gupta <pankaj.gupta@....com>
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

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.

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.

Thanks
Frieder

Powered by blists - more mailing lists