Re: [EXT] Re: [PATCH v18 3/7] firmware: imx: add driver for NXP EdgeLock Enclave

[Marco Felsch <m.felsch@pengutronix.de>]

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.

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

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

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

(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?)

For OP-TEE you need to:
 - setup the context
 - switch the CPU mode
 - make use of ARMv8 Crypte-Extensions

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.

Are there measurements/application-notes that show that the usage of the
ELE is more performant than using the crypto-extensions?

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

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.

Regards,
  Marco