Don't know where to ask this, current TF-M design allows only for one secure cpu and one non-secure?
Why not have SPE and NSPE on both cores, as would be possible on mps2/an521 e.g. (dual M-33 with TrustZone). Could TF-M be modified to allow for such a behavior in the current version?
Thankful for any answers!

Hi Martin, this *dual-cpu* design is dedicated for the platforms which consist of a non-secure core and a secure core. The secure core is protected from the non-secure core by system physical isolation. PSoC 64 is an example port of this *dual-cpu* implementation.

There does be a similar use case in TF-M :). Please check Musca-B1 Secure Enclave.

Musca-B1 consists of two Cortex-M33 cores, both of which have TrustZone. TF-M run on both core. PSA RoT services run on *Secure Enclave* core. NS and App RoT services run on the *Host* core (like a standalone Armv8-M with NSPE and SPE). *Host* core will forward PSA RoT service requests to *Secure Enclave* core, via the mailbox designed in this *dual-cpu*.

Hi David. What about a scenario where non-secure applications want to use both cores? I think this is what Martin is asking about. Dedicating one M33 to act as a secure enclave can be considered a waste of compute resource (it will be idle most of the time).

Yes this was indeed what I was thinking about. I am now trying to modify the secure enclave implementation to work with both CPUs in the SSE 200 on the MPS2 AN521 image. This would also also both cores to still be used by nonsecure OS / applications

@MartinSchoenstedt so are you trying to run Non-secure OS + TF-M on both MPS2 AN521 cores?
Are you designing a SMP (symmetric multiprocessing) system for both NS and S? May I know the benefit to run NS + TF-M on both cores, compared to running a single Cortex-M33?

So far, a single TF-M instance is unable to run on multiple cores. In dual-cpu and SE scenarios, the mailbox communication between cores is unidirectional actually.
Assumed that secure services are not duplicated in your multi-core scenario, synchronizing the NS/S statues of cores can be a critical problem to enable single TF-M on multiple cores.

The concept I am working on would allow for execution of two NS environments both with access to TF-M services. The goal is also to isolate the NS environments from one another to provide safety in case of failure / maliciousness of one NS env. But this safety feature is not necessary for the use case of two Cortex M-33 with NS + TF-M.

But in all cases using both cores available on the platform can be beneficial for multiple use cases. As Adrian has stated, blocking a complete core for TF-M execution seems less than ideal.

After deeper investigations into the mailbox system (which is not really what I was looking for), I am thinking about what changes to single-core TF-M would be necessary to enable a multi-core scenario

Imo, the implementation can be very platform specific. It is required that the two cores shall be physically isolated.
Besides, when NS requires secure services on the other core, the other core must runs in S world. It is a bit difficult to guarantee.

Is it possible to achieve the same isolation between the two NS instances, if implementing them as two isolated application on a single core?

If the NSPE can use all the ARMv8-M processors, then it makes sense to use a model similar to ARMv8-A. In that model, the request for a secure service is usually handled by the local core - no cross core interaction.

However, this is totally different (and orthogonal) to the existing twin-cpu design. It sounds like a separate proposal altogether. And it sounds quite challenging to achieve with the current codebase. You could either have two instances of TF-M (one for each core, both in secure state) or you modify TF-M to be multi-core aware. Having multiple instances doesn't make much sense if they are stateful services.

In either case, one of the significant challenges is that the services within the Secure Partitions are single threaded. PSA Firmware Framework does not allow multiple threads within a Secure Partition and does not define any mutex primitives.

Thanks @adrianlshaw for your comment. A multi-core TF-M design is indeed a different thing than this twin-cpu design or any of the implemented designs for multiple CPUs in TF-M.
Do I understand you correctly, that such a multi-core TF-M design would not be possible to design according to PSA FF-A guidelines, because no mutex is defined in these?
How is this problem handled in TF-A as the same PSA guidelines apply there?
I somehow messed up the two files and got confused

Hi Martin. I was referring to PSA FF-M, not FF-A. See the spec here, in Section 2.1. TF-A conforms to FF-A, which is a different spec.