> Am 30.06.25 um 14:17 schrieb Marco Felsch: >> Hi Frieder, >> >> On 25-06-30, Frieder Schrempf wrote: >>> Hi Marco, >>> >>> Am 27.06.25 um 10:46 schrieb Marco Felsch: >>>> 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. >>> >>> Do we really want to depend on OP-TEE to be available for having >>> things like OTP fuse access and HWRNG? Personally I'd like to be able >>> to build systems with OTP access and HWRNG but without OP-TEE. >>> Requiring OP-TEE only to make the ELE available to the kernel in >>> cases where the secure world isn't used for anything else seems to be unnecessarily complex. >> >> I understand your point. I don't like pulling in more FW neither but >> we need to the face the following facts: >> >> - OTP eFuse R/W access after doing the LOCK_DOWN fuse is no longer >> possible without OP-TEE. This involves general purpose (GP) eFuses >> too. We faced this limitation in a current project. > Ok, interesting. Where do find information about the LOCK_DOWN fuse? I don't see it mentioned in the (Security) Reference Manual of the i.MX93.
