Marking the issue as closed taking into account the inactivity on this thread.
I suggest opening a new issue/issues - with finer incremental aims if possible - based on the present status of the project if needed.

In line with your latest comment and the closure of the corresponding issue T421 referred to by @tamasban , I am closing this thread.
I suggest to open a new issue and refer back to this thread if there are related comments on the present state of the project.

Since the change referred to in the original issue (https://review.trustedfirmware.org/c/trusted-firmware-m/+/1123) has been abandoned with an alternative added to the comments for that review, I am closing this thread.
I suggest that considering the time elapsed since the last comment to open a new issue and refer back to this if there are related comments on the present state of the project.

The aforementioned fix was merged on 26 July, 2019. Closing this issue.

Various aspects of this task are to be addressed in different broader conceptual changes in the code base.

As I believe the change has been implemented with the new scope, I'm re-assigning the ticket to Mate, the owner of the change.

Revisiting this topic:

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.

The NS lock is initialized at a point in time when the scheduler is not yet started, therefore there is a single thread of execution on the NS side.
I agree it is safe to assume that in such a scenario, the only actor on the NS side is privileged and therefore is assumed to be in full control of execution, there are no separate protection domains within NSPE.
Secure lock is already set up so there's no risk of introducing new exploits with this change.

https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/951/ reviewed, approved, upstreamed

Due to increased interest in this feature and no objections to the implementation concept, I'm raising the priority and will rebase my proposal change and do some polishing to make it a good candidate for upstreaming.
The suggested change of naming convention was discussed offline but was deemed unnecessary as there's limited risk of the feature being misunderstood and that is planned to be mitigated by improved documentation, while the design pattern evoked by the current name is hopefully a reasonable point of reference.

Fix for second issue:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1197/

Upstreamed

Thanks, the change is approved.

Could you provide details of the compiler configuration where you received this error?
We may need to update the configurations in CI to capture similar shortcomings.
I will execute some rudimentary tests in the meantime.

See below review for corresponding change:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1152/

Please see the review below for proposal:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/951/

The transition from NS to S using the psa_call veneer has an implementation-defined layer of serialization in addition to what is prescribed in the PSA client API, necessary because of the limitations on parameter passing between security states.
The argument list mentioned above:

psa_status_t tfm_psa_call_veneer(psa_handle_t handle,
        const psa_invec *in_vecs,
        const psa_invec *out_vecs);

has those data types by design: both the invec array and outvec array are serialized to one invec each, i.e. two input parameters for the secure veneer, one containing the array of invecs, the other containing the array of outvecs.
From the veneer point of view both are constant input parameters, hence the const psa_invec type.
When extracting the arrays from these vectors in tfm_svcalls.c you can see the deserialization to the PSA-defined data types:

outptr = (psa_outvec *)((psa_invec *)args[2])->base;
out_num = ((psa_invec *)args[2])->len;

Please note that secure SVC is running on highest priority. Execution of this code cannot be pre-empted by either NSPE or any external secure interrupt. This is essentially a critical section.

Hi Ken,

Please see https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_signature/ for detailed design proposal

A bugfix is provided for incorrect default behaviour if NS client identification is turned off in the build environment in change:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/378/

Implemented by https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/364/

Design documented at https://developer.trustedfirmware.org/w/tf_m/design/ns_client_management/

Change submitted.

Change and related improvements upstreamed

https://review.trustedfirmware.org/#/c/191/ is a proposed resolution for this change.

Based on @gyuri-szing's comment on the review I split the change to two parts:
https://review.trustedfirmware.org/#/c/174/ only fixes the upstream to keep NS exceptions disabled during secure execution by default as is the current assumption for TF-M.
Change https://review.trustedfirmware.org/#/c/183/ introduces the switch. Gyorgy's comment can be debated separately this way without blocking the fix.

In my view we should investigate other options for having the API definitions stand out from the service internal files.
There is an ongoing effort to limit the number of steps that need to be taken in order to integrate a new partition into the system, or to disable/enable one that is already present.
I would therefore suggest to keep service API files in the service folder and not create a new location for them.

Change on review at:
https://review.trustedfirmware.org/#/c/174/

The change has been merged on both branches

Mate is working on the prototype while I'm writing the design document.

The same two changes for the feature-ipc branch:
https://review.trustedfirmware.org/#/c/145/
https://review.trustedfirmware.org/#/c/146/

https://issues.trustedfirmware.org/T39 to follow up on updates needed for newer version of PSA spec and updates, reduction of proprietary fields

First batch of related changes upstreamed.
https://review.trustedfirmware.org/#/c/85/
https://review.trustedfirmware.org/#/c/86/
https://review.trustedfirmware.org/#/c/87/
https://review.trustedfirmware.org/#/c/88/
https://review.trustedfirmware.org/#/c/89/
https://review.trustedfirmware.org/#/c/90/
https://review.trustedfirmware.org/#/c/91/