[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250627084653.6vgwnm3llf3zknlp@pengutronix.de>
Date: Fri, 27 Jun 2025 10:46:53 +0200
From: Marco Felsch <m.felsch@...gutronix.de>
To: 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,
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.
Regards,
Marco
Powered by blists - more mailing lists