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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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