Hi Gilles,
Thank you very much for your answer. It makes a lot of sense! As of the restriction, it is something with the hardware.
Appreciate your answer very much!
Best regards,
Hao ________________________________ From: Gilles Peskine gilles.peskine@arm.com Sent: Thursday, June 6, 2024 1:05 PM To: Zhang, Hao Hao.Zhang@analog.com; Shebu Varghese Kuriakose Shebu.VargheseKuriakose@arm.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [mbed-tls] Re: PSA Cryptoprocessor Driver Interface
[External]
I'll just answer the interface question, I don't know about the TF-M part.
On 05/06/2024 22:48, Zhang, Hao wrote:
1. For multi-part operation, as you mentioned, the abort needs to deallocate resources. If there are some restrictions that prevents deallocating resources in the middle of aead operation, could it be that aead_abort returns PSA_ERROR_NOT_SUPPORTED?
No, the driver should not return NOT_SUPPORTED, because an application has no good way to react to that. The application would have an operation object that can neither be used nor freed. In practice applications may either ignore errors from abort() or panic.
abort() can always be implemented by simulating a complete operation (e.g. finish() or verify()) with empty inputs, ignoring any further output.
But I'm curious: what would prevent deallocating resources? The only thing I can think of is concurrency, but operations are sequential: there can't be concurrent calls on the same operation object from different threads, so abort() won't be called while another thread has the operation locked.
Best regards,
-- Gilles Peskine