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
