NSPE lock cb isn't allocated
Open, Needs TriagePublic

Description

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

orenc17 created this task.Feb 6 2019, 2:03 PM
adeaarm added a subscriber: adeaarm.EditedFeb 6 2019, 5:17 PM

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?

From what we've seen mbed-os disables the "Automatic Dynamic Allocation"

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.