Hi Varun, > > Hi Marco, > Please find response inline. > > Regards > Varun > > > > > > > ... > > > > > > > > > > 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. Agree. > > > > > 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. > > > > > > 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. Agree. > > > > > 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. Agree > > > > > 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. > Agree. > > > > Regards, > > Marco
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
