Message-ID:
 <AM9PR04MB8604F5A7DD8B1E41FDAD09039501A@AM9PR04MB8604.eurprd04.prod.outlook.com>
Date: Wed, 3 Sep 2025 09:18:21 +0000
From: Pankaj Gupta <pankaj.gupta@....com>
To: Varun Sethi <V.Sethi@....com>, 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>, Sahil Malhotra
	<sahil.malhotra@....com>
Subject: RE: [EXT] Re: [PATCH v18 3/7] firmware: imx: add driver for NXP
 EdgeLock Enclave

Hi Varun, 

> 
> Hi Marco,
> Please find response inline.
> 
> Regards
> Varun
> 
> >
> > > > ...
> > > >
> > > > > > 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.
> >
> > I don't get this. You introduce even more segmentation if the read-path
> uses
> > another driver than the write-path and if this is optional.
> >
> [Varun Sethi] The secure enclave firmware can restrict accesses to fuses
> based on the MU (from where the request is received) and core security
> state. So, we are not talking about segmentation but rather partitioning.

Agree.

> 
> > > > 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.
> >
> > Which is correct and no reason for not having an OP-TEE only solution.
> [Varun Sethi]Yes, driver instances would be available in both OP-TEE and
in
> Linux. Secure enclave services exposed by these instances would vary.

Agree.

> 
> >
> > > 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.
> >
> > Of course, the ELE communication itself will be faster if Linux
> communicates
> > directly with the ELE instead of going through OP-TEE.
> >
> > But to be honest I don't think that the ELE usage itself is much faster
> than
> > using OP-TEE and the ARMv8 Crypto-Extensions.
> [Varun Sethi] That's true, the main point for using secure enclave is
about
> key protection at rest and runtime.
Agree.

> 
> >
> > For the ELE you need to:
> >  - setup the context (incl. the message and all mailbox mechanism)
> >  - wait for the ELE to be accessible (only one ELE, only one
> >    normal-world MU).
> >  - transfered the messages to/from the ELE
> >  - the ELE processing should be equal to the CPU processing time
> [Varun Sethi] Well, this is similar to any look aside accelerator.
> 
> >
> > (Side note: What is the ELE behavior if the secure-world stresses the
ELE?
> > Is there a MU priority so the normal-world MU may get blocked (never
> > addressed) or are both MUs scheduled in round-robin?)
> [Varun Sethi] Priority based message handling is a possibility but
currently
> it's round robin.
> 
> >
> > For OP-TEE you need to:
> >  - setup the context
> >  - switch the CPU mode
> >  - make use of ARMv8 Crypte-Extensions
> [Varun Sethi] You will also have an option to use the secure enclave via
> OPTEE.
Agree

> 
> >
> > On i.MX8M, which uses the CAAM (the ELE predecessor), we can verify that
> the
> > ARMv8 crypto extensions are much faster than the crypto-engine itself.
> > Therefore the CAAM is mostly unused.
> [Varun Sethi] CAAM does offer capability for runtime and at rest key
> protection. That capability is used by multiple customers.
> 
> >
> > Are there measurements/application-notes that show that the usage of the
> ELE
> > is more performant than using the crypto-extensions?
> >
> [Varun Sethi]It's not more performant but offers protection for secrets.
> 
> > > IOT-cases where real-time encrypted feed from sensors, will take
> > > latency hit.
> >
> > Does the ELE support inline en-/decryption? If not, I don't think so.
> [Varun Sethi] Again, it's about key protection. It's possible to combine
> secure enclave key protection with other high performance crypto
> accelerators.
> 
> >
> > The data needs to be read from the CPU first, afterwards it needs to be
> > prepared for the ELE and transfered to/from the ELE. Also there is just
a
> > single ELE with a single normal-world MU, so you need to handle
> concurrent
> > access if there are multiple ELE-users (sensor+tls-offloading).
> >
> > If CPU is used, the data still needs to be read from the communication
> > interface but afterwards doesn't need to be passed to another IP. Also
> there
> > are multiple CPUs.
> [Varun Sethi]You are right, but please note that secure enclave offers key
> protection and offers support for asymmetric crypto operations. So, for
> cases where we need to establish secure TLS/IPSec connection and ensure
> protection for long term secrets (asymmetric keys) secure enclave is
> suitable. For bulk crypto operations you can use high performance crypto
> accelerators along with secure enclave.
> 
> Secure enclave use cases can vary for OP-TEE and Linux. We are enabling
> drivers for both environments.
> 
Agree.
> >
> > Regards,
> >   Marco

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

Powered by blists - more mailing lists