Message-ID: <20250806132701.fouikyuqtzdsxqwh@pengutronix.de>
Date: Wed, 6 Aug 2025 15:27:01 +0200
From: Marco Felsch <m.felsch@...gutronix.de>
To: Pankaj Gupta <pankaj.gupta@....com>
Cc: Frieder Schrempf <frieder.schrempf@...tron.de>,
	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

On 25-08-06, Pankaj Gupta wrote:
> > On 25-07-09, Pankaj Gupta wrote:
> > > > Am 30.06.25 um 14:17 schrieb Marco Felsch:

...

> > Lockdown: For a verified boot setup you need to burn an eFuse at some
> point,
> > to tell the bootROM to boot only correct verified firmware images.
> > 
> > After this lockdown it's no longer possible to burn eFuses from the REE
> albeit
> > the production line setup still requires the support.
> > 
> Understood. ELE access from both secure and non-secure world is fixed in Q3
> release.
> User can be able to modify eFuses via OPTEE.

Splitting the read and write between two drivers is even worse.

Can you please point out why you can't just move the driver parts into
the tee? I do see many advantages if only op-tee is used:

 + Minimize the maintainer effort, because only one driver
   implementation is used.
 + TEE code could be reused by other OSes
 + You could already start adding the support for it to OP-TEE because
   no ELE-FW update is required.
 + TEE is used anyway for new projects due to CRA and friends
 + Concurrent access handling is done by the TEE core

The only downside of this approach is the integration effort for the
TEE, but this shouldn't be an excuse. Mostly all well known buildsystems
like: Yocto/OE, buildroot, ptxdist do have mainline support for OP-TEE.

> > > >>  - 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.
> > 
> > Once again, still no fix available and if your system requires a TEE
> you're forced
> > to move the ELE communication into the TEE (at least until now).
> > 
> > Also the eFuse R/W access is not possible from the REE/Linux after doing
> the
> > device lockdown.
> > 
> ELE access from both secure and non-secure world will be fixed in Q3
> release.
> User can be able to modify eFuses via OPTEE.

NACK, please see my comment above.

> > > >>  - 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.
> > 
> > Please mention this within your commit message.
> Accepted & mentioned.
> 
> > 
> > > As mentioned earlier, there is an issue of using MUs simultaneously,
> > > from both worlds. Fix is in progress.
> > 
> > So until now no fix available and i.MX93 based products which do use a TEE
> > are forced to move the communication into OP-TEE.
> > 
> > > >> 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.
> > 
> > How exactly do you provide the eFuse write access after the device was
> locked
> > down?
> As mentioned above by you. It will be done via OPTEE-OS (or may be via TFA).

Why TF-A? Please see my comments above.

At the moment I don't see why the ELE must be a Linux driver. You could
start adding a TEE driver now, because there is no need to wait 3 months
for a ELE-FW fix.

IMHO having a dedicated normal-world driver makes only sense for
bootlaoders which don't have support for the TEE communication but need
access to the ELE. This is not the case for the kernel.

Regards,
  Marco

Powered by blists - more mailing lists