in interface\src\tfm_ns_lock_rtx.c, tfm_ns_lock_init() creates a new mutex without specifying a cb in the mutex attributes struct
on some OSes/toolchains the allocation of the control block is expected to be done by the user.
osRtxMutex_t should be defined in the file and described in the mutex atributes
The current implementation is based on the mechanism provided by the CMSIS-RTOS2 layer as default, which is the "Automatic Dynamic Allocation"
This method is the default one, generic and fully portable to other CMSIS-RTOS API v2 implementations and viable for many use cases.
On the other hand, providing a user-defined buffer would require this module to comply with RTX specific requirements (see Static Object Memory).
The rationale behind this choice was to prioritise flexibility and to be compatible with CMSIS (CMSIS-RTOS2).
Other OSes can provide their own implementation of this module in case they have specific requirements for static memory allocation.
Do you see any particular use case or reason why the current implementation should be amended to use RTX specific, static memory allocation for this lock?
In the case of integration with mbedOS in the NS side, I would expect the NS binary to provide its own implementation of the functionalities described in interface/include/tfm_ns_lock.h, instead of reusing the implementation that is available in interface/src/tfm_ns_lock_rtx.c, which is aimed specifically to CMSIS.