Message-ID:
 <AM0PR0402MB33631F1A9448AE91B58AA406E83AA@AM0PR0402MB3363.eurprd04.prod.outlook.com>
Date: Fri, 29 Aug 2025 11:33:50 +0000
From: Varun Sethi <V.Sethi@....com>
To: Pankaj Gupta <pankaj.gupta@....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>, 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

Hi Marco,
Please find response inline.

Regards
Varun

> -----Original Message-----
> From: Marco Felsch <m.felsch@...gutronix.de>
> Sent: 21 August 2025 18:51
> 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; imx@...ts.linux.dev;
linux-doc@...r.kernel.org;
> Frank Li <frank.li@....com>; linux-kernel@...r.kernel.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
> 
> Caution: This is an external email. Please take care when clicking links
or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
> 
> 
> On 25-08-21, Pankaj Gupta wrote:
> >
> >
> > > 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.
> 
> 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.
 
> > > 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. 

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

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

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

> 
> Regards,
>   Marco

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

Powered by blists - more mailing lists