One idea for heuristic. With NS secure call run-to-completion, it can run in interrupt-disabled context with mutex removed. For example, disable task switch during NS secure call period:

int32_t state = osKernelLock();
result = fn(arg0, arg1, arg2, arg3);
osKernelRestore(state);

The drawback of this idea, of course is apparent: other NS tasks cannot run in time.

My mbed-os/tf-m port on M2351 requires this support. Hope new idea can conquer this difficulty.

Hi @ccli8

TF-M does not need to be aware of any solution applied on the non-secure side to ensure serialization of secure calls. TF-M does not check the status of the NS lock, what it does is detects concurrent calls to the secure domain using a secure lock that is independent of the NS side implementation.
What we have in the repository for the NS lock is a reference implementation for a generic solution, but use of the non-secure lock is not - and cannot - be enforced by SPM. So if the NS OS you are using in your build exposes the functions you mention, your application is free to call them. It does not need support in the TF-M repository.
The only thing to note is that any proprietary implementation should ensure single entry to the secure domain as any concurrent calls would be flagged up as severe security violations. Any NS policy that avoids this scenario is transparent and acceptable.

Please let me know if this explanation is satisfactory or if you need further clarification - or if I'm misinterpreting your proposal.

Regards
Miklos

Hi @wmnt

So the NS lock in TF-M is a reference implementation. Proprietary implementation may be needed to meet target platform. But per my mbed-os/tf-m port, mbed-os team follows the rule of importing TF-M and not making modification to such as this NS lock implementation for its maintenance. That's one of my dilemma. My biggest dilemma is still how to make secure call in interrupt-disabled context at NS side of mbed-os. The NS lock mechanism with mutex apparently collides with interrupt-disabled context.

Hi @ccli8 ,

We have discussed this matter and we would like to propose a solution which might be feasible for you.

The TFM NS interface code is always meant as an example that system integrators can modify in their platform integration work to suite their particular requirements. It is unfeasible for us to have an NS interface code which could be a "one-size-fits-all" approach in terms of requirement compliance for partner platforms. We also understand that mbed OS currently uses the example code as is, thus the problem that you are facing where you need to modify the NS interface code to suit your requirements, would lead you to try to upstream a change in the TFM NS interface code rather than in your platform port in the mbed OS repo.

To try to provide a more abstracted interface and ease platform integration, what we would like to do is as follows:

1. All the code that is currently calling RTOS related APIs directly (for example based directly on CMSIS-RTOS2), needs to use the abstracted OS interface which is used only by the SST tests (available in os_wrapper.h). We can refine the APIs available in os_wrapper.h more easily without touching the TFM NS interface.
2. The example implementation of this OS abtraction layer is still upstreamed as part of the TFM NS interface code (example being based on CMSIS-RTOS2), but the example code there is marked as WEAK so that it can be replaced, at linking stage, directly by a more suitable alternative provided by the platform/system integrator to better suite their platform requirements (as that would be your case)
3. mbed OS will have to sync with TFM repo after this reorganisation has taken place to allow this kind of easier integration

With this approach, you should be able to provide your own implementation of RTOS related APIs in your platform port on the mbed OS repo and the TFM NS interface code can remain as is, in a more abstracted way, without any "platform specific" dependency.

Please let me know if this approach sounds reasonable to you. We welcome a direct contribution from your side on the TFM NS interface to do this clean up / refactoring.

Thanks,
Antonio

Hi @adeaarm

The WEAK mechanism sounds OK, but I think not just OS abtraction layer, the TFM NS interface (tfm_ns_lock_dispatch(...), tfm_ns_lock_init()) also needs to be WEAK. For the interrupt-disable scenario, the mutex-like reference implementation cannot apply, and the TFM NS interface may need to implement in a wholly different way.

Still for the interrupt-disable scenario, please advice when there is workabe idea.

Possible refactoring available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1460

This will be completed by an additional refactoring to use abstracted OS interface when possible (i.e. os_wrapper_*) to be done by @kevin-peng-hao . Please use this ticket to keep track of the additional change.

Patches for additional refactoring:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1698
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1699
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1700
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1701