This is related to https://lists.trustedfirmware.org/pipermail/tf-m/2019-December/000581.html.
Pictures are filed here as the email list does not support pictures.

In T615#7152, @ReinhardKeil wrote:

This is related to https://lists.trustedfirmware.org/pipermail/tf-m/2019-December/000581.html.
Pictures are filed here as the email list does not support pictures.

This diagram is correct for the SFC mode. For the NS client ID ("client-oriented policy" in the diagram), the users may use it for a different purpose. But it's OK to ignore if have no requirement.
The current RTOS integration enables the TZ API is to make it generic. If the specific implementation doesn't need multiple secure context and different NS client ID support, then they can leave the implementation empty.

TZ API is not generic - otherwise it would be widely supported by RTOSes. It is good that the implementation can be empty as there are also requirements to use TF-M without RTOS.

The "Client-oriented policy" is relative easy to overcome. I'm not sure that it adds real-world value for security. A simple access key might do the same job.

I suggest to add a define setting that removes from TF-M all code that is related to the TZ_context management interface.

Yes, the TZ API is not widely supported and the RTOSes which support v8m TZ are inventing their own "TZ" API for secure context switch (e.g. FreeRTOS). So, we intended to make the "Secure Context Management" ecosystem more aligned. For example, we are also introducing TZ API in RT-Thread.
But you're right, it's optional if there's no multiple secure context in TF-M. The value of NS client ID and NS access policy are use case specific. We provide the way to support that but it should be optional.
We will check if anything will go wrong if RTOS doesn't call the TZ API to TF-M. If we found issues, then will fix them.
Thanks for the valuable input!

Yes, looks like we can keep TZ context management as option to disable for RTOSes integrating TFM. There are RTOS vendors who have exprressed supporting multiple secure contexts in TF-M as a requirement.

There are some patches for conditional build for secure context management APIs:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3059
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3060

Are the patches now part of a release? I'm asking as there is a need to support PSA Certification for Level 2 with FreeRTOS.

Hi Reinhard, FYI the patches have been merged.

Thanks, Kevin.

Great, I asssue that this is configured with a #define.

What is the name of that #define?

Is there a central file that contains all the TF-M defines?

It's configured in CommonConfig.cmake, line #321.
The name is CONFIG_TFM_ENABLE_CTX_MGMT.