Re: [EXT] Re: [PATCH v18 3/7] firmware: imx: add driver for NXP EdgeLock Enclave

Am 30.06.25 um 14:17 schrieb Marco Felsch:

Hi Frieder,

On 25-06-30, Frieder Schrempf wrote:

quoted

Hi Marco,

Am 27.06.25 um 10:46 schrieb Marco Felsch:

quoted

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:

quoted

quoted

quoted

Add driver for enabling MU based communication interface to

secure-enclave.

quoted

quoted

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.

quoted

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 :(

quoted

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

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.

 - 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.

 - 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.

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.

quoted

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.