Hi Marco,
Please find response inline.

Regards
Varun

-----Original Message-----
From: Marco Felsch <redacted>
Sent: 21 August 2025 18:51
To: Pankaj Gupta <pankaj.gupta@nxp.com>
Cc: Frieder Schrempf <redacted>; Jonathan Corbet
[off-list ref]; Rob Herring [off-list ref]; Krzysztof Kozlowski
[off-list ref]; Conor Dooley [off-list ref]; Shawn Guo
[off-list ref]; Sascha Hauer [off-list ref]; Pengutronix
Kernel Team [off-list ref]; Fabio Estevam [off-list ref];
devicetree@vger.kernel.org; imx@lists.linux.dev;

linux-doc@vger.kernel.org;

Frank Li [off-list ref]; linux-kernel@vger.kernel.org;
linux-arm-kernel@lists.infradead.org; Varun Sethi [off-list ref]; Sahil
Malhotra [off-list ref]
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:

quoted

quoted

On 25-08-06, Pankaj Gupta wrote:

quoted

quoted

On 25-07-09, Pankaj Gupta wrote:

quoted

quoted

Am 30.06.25 um 14:17 schrieb Marco Felsch:

...

quoted

quoted

Lockdown: For a verified boot setup you need to burn an eFuse at
some

point,

quoted

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

quoted

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.
 

quoted

quoted

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. 

quoted

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. 

quoted

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