the changes will solve current issue, but it is only a partial solution. Full solution depends on https://developer.trustedfirmware.org/T244
It seems the way connection handle is allocated needs to be reworked, thus the changes proposed in https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/627/ will no longer be relevant.

I think we found temporary workaround on our side.
It is no longer a blocker for us, but still HP.
tnx

Miklos,
As always you are 100% right. I just wanted to provide simplistic example. Perhaps i've oversimplified :).
While you assumption is true for single core systems, it breaks on asymmetrical multi-core system where SPM is running on one core and NSPE on other.
TF-M is not supporting such a targets right now, but we are now working on a port for such a target.
I suggest to take this in to consideration while implementing new functionality.

the spec specifies that caller passes a pointer array of psa_invec. The array is allocated in caller memory, thus is modifiable by a caller at any time.
SPM must first copy each individual psa_invec to SPM own memory, and only then verify accessibility of each individual range.

from what i see invecs are not copied. Perhaps i'm looking at outdated sources? https://review.trustedfirmware.org/c/trusted-firmware-m/+/468/1/secure_fw/core/ipc/tfm_svcalls.c#131

in_vec = (psa_invec *)((psa_invec *)args[1])->base;
in_num = ((psa_invec *)args[1])->len;
out_vec = ((psa_outvec *)args[2])->base;
out_num = ((psa_outvec *)args[2])->len;

Please note that newer version of PSA FF spec introduced a change to psa_get API especially to address this issue. psa_get now return an error code (it had void return value before and was not allowed to fail).
PSA_ERR_NOMSG is a special error code that can be returned from psa_get if you encounter resource allocation issue.
SP should then ignore current signal and retry later on.

isolation level 3 assumes mutual distrust between secure partitions.
we need to save connection "owner" client ID and not only secure domain origin.