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);
if (additional_data == NULL) { in_len--; } status = psa_call(TFM_CRYPTO_HANDLE, PSA_IPC_CALL, in_vec, in_len, 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 ________________________________ From: Quach, Brian via TF-M tf-m@lists.trustedfirmware.org Sent: Monday, June 3, 2024 23:42 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] API_DISPATCH for tfm_crypto_api.c
Hi,
I noticed that trusted-firmware-m\interface\src\tfm_crypto_api.c defines two API_DISPATCH macros for psa_call(). It is used most of the time in the file, but I still see ~10 instances where psa_call() is used. Can it be changed to consistently use the API_DISPATCH macros.
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.