Hi, your e-mail configuration mixed my e-mail with your answer, which makes it hard to read. Can you please check the quoting next time :) On 25-06-27, Pankaj Gupta wrote: > >> Add driver for enabling MU based communication interface to > secure-enclave. > >> > >> NXP hardware IP(s) for secure-enclaves like Edgelock Enclave(ELE), are > >> embedded in the SoC to support the features like HSM, SHE & V2X, using > >> message based communication interface. > >> > >> The secure enclave FW communicates with Linux over single or multiple > >> dedicated messaging unit(MU) based interface(s). > >> Exists on i.MX SoC(s) like i.MX8ULP, i.MX93, i.MX95 etc. > > > You write single or multiple MUs are possible. I'm aware that the i.MX93 > > has two MUs one for the secure and one for the non-secure world. But I'm > > really concerned about the fact that both MUs can't be used at the same time > > from both world: > > Yes, you are correct. > > Fix is still work in progress. So after ~6 months no fix is available :( > > Also how is the secure and non-secure world talking to the ELE if there is > > only one MU as you have written? > > Till the fix is WIP, either Linux or OPTEE can use the ELE, at one point in > time. That has nothing to do with the fix. The fix is for platforms/SoCs which do have 2-MUs, but you also have written that there are platforms with only 1-MU. This MU can't be shared between secure and non-secure world. > > IMHO it makes much more sense to put the complete ELE communication into > > (OP-)TEE and let the secure OS taking care of it. All non-secure world > > requests are passed via (OP-)TEE to the ELE. This involves: > > - eFuse access (done via OP-TEE i.MX specific PTA) > > - ELE 23h59m ping (kernel SMC WDG driver, requires OP-TEE watchdog driver) > > - HW-RNG (kernel OP-TEE HWRNG driver + OP-TEE HWRNG PTA) > > There is a dedicated MU "trusted-MU" for OPTEE-OS. The idea to converge to a Yes for systems with 2-MUs there is a "trusted-MU" and a "non-trusted-MU". As of now, there is no fix available for using both MUs at the same time. Furhtermore there are platforms/SoCs with only 1-MU, as you have written in your commit message. This 1-MU system can have the MU either trusted or non-trusted. > single path via OPTEE-OS, is good. But it will impact the performance of the > features at Linux side. Performance? We are talking about a ping every 23h59m (I still don't know if this is a feature or bug), eFuse write/read, and the HW-RNG which can seed the Linux PRNG. > Since the fix is still WIP. Let's wait till then. The fix is for the 2-MUs SoCs but not the 1-MU case. I would like to have a system design which doesn't differ too much between SoCs which are equipped with the ELE engine. Regards, Marco
