The message memory allocation works freely and may fail in corner cases, which may cause psa_call to fail on a connected channel. This is not aligned with PSA FF specification.
This mechanism needs to be enhanced.
Description
Event Timeline
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.
To take advantage of this error code we should make sure that active message is allocated from SPM memory only during psa_get API call. And not during psa_call.
IPC model assumes that psa_call client call can be queued. And psa_get is called by SP when it actually ready to handle the message.
From security perceptive, we must copy incoming data(iovec pointers and sizes) to SPM memory to prevent TOCTOU. It is acceptable to postpone the copy to actual use time. SPM cannot protect callers, so the input data can theoretically be modified even before psa_call was made. The only thing SPM must make sure iovec pointer and sizes remain unchanged during IPC message actual handling as there are multiple access to the during psa_read/write commands.
I think the mechanism is changed during this patch:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1744
Now one handle could only have one message body, and this message body is allocated while handle is created. So there is no resource allocation issue for the message (we do have this problem for handle but this ticket is not the case). Close this task as done.