Message-ID:
 <AM9PR04MB8604A636762E81DF9EA9A9B89532A@AM9PR04MB8604.eurprd04.prod.outlook.com>
Date: Thu, 21 Aug 2025 11:59:35 +0000
From: Pankaj Gupta <pankaj.gupta@....com>
To: Marco Felsch <m.felsch@...gutronix.de>
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>, Varun Sethi <V.Sethi@....com>, Sahil
 Malhotra <sahil.malhotra@....com>
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.

This could be use-case dependent. Depends on how customer will deploy its
solution.

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

The ELE's KEY derivation function takes account of world from where, the
operations are requested.
- The key derived from secure world and from non-secure world will be
different.
There are different use-case for ELE accesses from both the worlds.

Using OPTEE ELE driver for Linux specific ELE-HSM requests, it will add
significant overhead.
Usecases like Transparent TLS offload while securing the secrets in HSM,
would incur additional overhead.

IOT-cases where real-time encrypted feed from sensors, will take latency
hit.

> 
>  + 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.
As answered above, we do need support of ELE driver in both worlds.
  
>  + TEE is used anyway for new projects due to CRA and friends  +
Concurrent
> access handling is done by the TEE core

As answered above, we do need support of ELE driver in both worlds.
> 
> 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.
> 
As answered above, we do need support of ELE driver in both worlds.

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

Download attachment "smime.p7s" of type "application/pkcs7-signature" (11094 bytes)

Powered by blists - more mailing lists