Hi Varun, 

Hi Marco,
Please find response inline.

Regards
Varun

quoted

quoted

quoted

...

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.

quoted

quoted

quoted

quoted

quoted

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

quoted

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.

quoted

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.

Agree.

quoted

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

quoted

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

quoted

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.

quoted

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.

quoted

(Side note: What is the ELE behavior if the secure-world stresses the

ELE?

quoted

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.

quoted

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

quoted

On i.MX8M, which uses the CAAM (the ELE predecessor), we can verify that

the

quoted

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.

quoted

Are there measurements/application-notes that show that the usage of the

ELE

quoted

is more performant than using the crypto-extensions?

[Varun Sethi]It's not more performant but offers protection for secrets.

quoted

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.

quoted

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

quoted

single ELE with a single normal-world MU, so you need to handle

concurrent

quoted

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

quoted

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.

quoted

Regards,
  Marco