Hi Marco, Please find response inline. Regards Varun > -----Original Message----- > From: Marco Felsch <m.felsch@xxxxxxxxxxxxxx> > Sent: 21 August 2025 18:51 > To: Pankaj Gupta <pankaj.gupta@xxxxxxx> > Cc: Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>; Jonathan Corbet > <corbet@xxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski > <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; Shawn Guo > <shawnguo@xxxxxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>; Pengutronix > Kernel Team <kernel@xxxxxxxxxxxxxx>; Fabio Estevam <festevam@xxxxxxxxx>; > devicetree@xxxxxxxxxxxxxxx; imx@xxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx; > Frank Li <frank.li@xxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Varun Sethi <V.Sethi@xxxxxxx>; Sahil > Malhotra <sahil.malhotra@xxxxxxx> > 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
