Hi Brian,

the API_DISPATCH macro uses the IOVEC_LEN() macro itself inside to automatically compute the lengths of the invec and outvec that are sent to the service. This unfortunately does not work for several APIs where the length of the IOVECs (either invec or outvec) is reduced by the interface API before sending. Take for example the aead_encrypt API:

    size_t in_len = IOVEC_LEN(in_vec);

                      out_vec, IOVEC_LEN(out_vec));

This is what the API performs before calling the actual psa_call: it evaluates whether the additional_data is a valid pointer or not, and if not, it will reduce the in_len by one. Calling the API_DISPATCH macro here would just use the value of IOVEC_LEN(in_vec) which would not take into consideration whether additional_data is a valid pointer or not, thus leading to a TFM_PANIC (NULL pointers, while acceptable from the API point of view, can't be passed to TF-M as the SPM won't be able to validate them).

Note that this pattern is used so that in_vec / out_vec can still be allocated statically in the interface API, but their length is then compute dynamically at runtime when it is reuqired to evaluate the pointers validity. 

From a quick look that I had at all cases that use psa_call directly, they all fall into this category either for in_vec or out_vec. But please let me know if you think otherwise.

Thanks,

Antonio