Thanks for the explanation Antonio. You are correct. I missed that.

Regards, Brian

From: Antonio De Angelis Antonio.DeAngelis@arm.com Sent: Wednesday, June 5, 2024 5:10 PM To: tf-m@lists.trustedfirmware.org; Quach, Brian brian@ti.com Cc: nd nd@arm.com Subject: [EXTERNAL] Re: API_DISPATCH for tfm_crypto_api.c

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 ZjQcmQRYFpfptBannerStart This message was sent from outside of Texas Instruments.

Do not click links or open attachments unless you recognize the source of this email and know the content is safe. If you wish to report this message to IT Security, please forward the message as an attachment to phishing@list.ti.commailto:phishing@list.ti.com

ZjQcmQRYFpfptBannerEnd 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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Monday, June 3, 2024 23:42 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto: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.