> On 25-07-09, Pankaj Gupta wrote: > > > 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. > > > > From i.MX9x & onwards, SoC(s) has at least one dedicated ELE MU(s) for > > each world - Linux(one or more) and OPTEE-OS (one or more). > > Okay, please re-phrase your commit message than, since this wasn't clear to > me. > Will update the commit message. > > As mentioned earlier, the fix for the issue of using OPTEE-OS > > dedicated MU on i.MX93, is identified & under testing. > > I get this but there is still no fix available after ~6 months, so it's still no possible > to use a TEE and REE in parallel. Yes. I understand this issue is of high importance. We are working on this. We will be able to provide the fix in the NXP Q3 quarterly release. > > > Other point on whether OTP effuse are R/W access, after LOCK_DOWN fuse? > > Not sure about how "doing the LOCK_DOWN fuse"? > > Please elaborate more on this. > > 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. > > >> - With new regulations like the EU CRA I think we need some sort of > > >> secure-enclave anyway. > > > > > Probably some sort of, yes. But not necessarily in the form of TEE > > > or TrustZone, I guess. > > To use ELE features through Linux, there is no dependency on OPTEE-OS. > > Once again, still no fix available and if your system requires a TEE you're forced > to move the ELE communication into the TEE (at least until now). > > Also the eFuse R/W access is not possible from the REE/Linux after doing the > device lockdown. > ELE access from both secure and non-secure world will be fixed in Q3 release. User can be able to modify eFuses via OPTEE. > > >> - Making it optional cause more paths of potential errors e.g. by not > > >> including the correct "secure.dtsi". Multiple paths also require more > > >> maintain- and testing effort. IMHO I do think that one of the paths > > >> get unmaintened at some point but we would need to keep it for > > >> backward compatibility. > > >> > > >> Having one implementation eliminates this since. > > >> > > >> - All above points assume that the ELE-FW and -HW is capable of talking > > >> to both world, which is not the case. As we learned NXP doesn't have > > >> a fix for the 2-MUs ELE yet and even more important there are 1-MU > > >> ELE-IPs. > > > > For i.MX9x SoC(s) there is at least one dedicated ELE MU(s) for each > > world - Linux(one or more) and OPTEE-OS (one or more), that needs to > > be shared between them. > > Please mention this within your commit message. Accepted & mentioned. > > > As mentioned earlier, there is an issue of using MUs simultaneously, > > from both worlds. Fix is in progress. > > So until now no fix available and i.MX93 based products which do use a TEE > are forced to move the communication into OP-TEE. > > > >> I do see the (minimal) drawback of having +1 FW but I think this is > > >> more an integration problem. > > >> Speaking of FW files, for the new i.MX9* you already have plenty fo > > >> them: bootloader, TF-A, ele-fw, scu-fw (i.MX95). So your integation > > >> needs to handle multiple firmware files already. > > > > > Sure, but I really like to keep the complexity and therefore the > > > number of FW files as low as possible. I'm not sure what has more > > > weight in terms of > > > security: shipping an additional firmware and therefore increasing > > > the attack surface or maintaining an additional code-path. > > > > There is no +1 firmware in case of i.MX93. > > > > >> > > >>> Anyway, I see your point of having a single implementation for the > > >>> ELE API in the "right" place. But as far as I know other platforms > > >>> like > > >>> STM32MP1 also implement both ways for the HWRNG, secure access via > > >>> OPTEE and non-secure access via kernel directly. > > >> > > >> I'm not a STM32MP1 expert but here you have this setup with the > > >> *-scmi.dtsi. So you have two code paths which needs to be > > >> maintained and tested. Also if one customer of yours want to use > > >> OP-TEE you need the integration anyway, so you (Kontron) needs to > > >> maintain multiple configuration as well. I don't see the added value. > > >> > > >> I think for STM32MP1 the *-scmi.dtsi support was added later > > >> because it required a lot effort to support it. This is not the > > >> case for the > > >> i.MX9* series. > > > > > Anyway, thanks for elaborating. Your points are all valid and > > > basically I > > agree. I'm fine with either way. But I'm afraid that implementing the > > ELE API in OP-TEE only will cause another tremendous delay for having > > ELE access in the kernel, especially seeing how slow NXP seems to be > > working on these topics right now. > > > > To use ELE features through Linux, there is no dependency on OPTEE-OS. > > How exactly do you provide the eFuse write access after the device was locked > down? As mentioned above by you. It will be done via OPTEE-OS (or may be via TFA). > > Regards, > Marco
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
