Hi Archanaa,

Current client key attributes is what need to be set by the PSA crypto client. domain parameters is not required by client in current usage, but we will consider it if it is needed in future use or required by users.

interface>include>psa>crypto_struct.h is referring to mbedtls crypto_struct.h. Mbed TLS do not simply define psa_reset_key_attributes() as static inline function in crypto_struct.h, so tf-m follows Mbed TLS implementation. I think the benefit is that it will be easier for us to maintain. But it is a good input, I will discuss it with my team member and consider your suggestion : )

Best Regards, Summer

________________________________ From: S Krishnan, Archanaa archanaask@ti.com Sent: Friday, July 29, 2022 10:10 PM To: Summer Qin Summer.Qin@arm.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Intended use of psa_reset_key_attributes()

Hi Summer,

Thank you. You are correct, reset key attributes in mbedTLS also free’s the domain parameter pointer apart from setting the core parameters in attributes to zero.

In the current TF-M implementation, by letting mbedTLS reset the attribute, mbedTLS is creating a new pointer when client attribute is translated to server attribute and freeing it on secure side. Since there are no pointers in the client side attributes, mbedTLS is freeing a pointer that does not exist on the client side.

Is there plan to change the PSA API to add pointers to client attributes? Otherwise, this function incurs the overhead of PSA call to reset a non-secure structure of uint32_t and uint16_t members.

An simpler alternative is to reset the client attributes along with other psa_set and psa_get functions in interface>include>psa>crypto_struct.h. Was this considered before and not implemented for any reason?

Regards, Archanaa

From: Summer Qin Summer.Qin@arm.com Sent: Friday, July 29, 2022 4:35 AM To: tf-m@lists.trustedfirmware.org; S Krishnan, Archanaa archanaask@ti.com Cc: nd nd@arm.com Subject: [EXTERNAL] Re: Intended use of psa_reset_key_attributes()

Hi Archanaa,

Thanks for feedbacking this.

An attribute object can contain references to auxiliary resources, for example pointers to allocated memory or indirect references to pre-calculated values. In order to free such resources, the application must call psa_reset_key_attributes().

In my personal understanding, the reset key attributes operation is not only reset (set to 0), it also includes memory free (if you check mbedtls implementation). From tfm perspective, we should do the key attributes structure translation between client and server, and let Mbed TLS help do the real reset operations.

Best Regards,

Summer

________________________________

From: S Krishnan, Archanaa via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, July 29, 2022 7:00 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Intended use of psa_reset_key_attributes()

Hi,

What was the intended usage of psa_reset_key_attribute(*attributes) which requires a PSA call from non-secure side to reset the client attributes? I am curious because the attributes to be reset comes from the non-secure memory, not directly associated with ITS/PS.

The current IPC setup performs a PSA call to tfm_crypto_rest_key_attributes()(https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/p...)

This function creates a copy of client key attribute in a secure key attribute structure. The secure key attribute is reset (set to 0) and then copied back to the client key attribute before returning to non-secure code. At first glance, this seems like a roundabout way to zeorise client side attributes.

Regards,

Archanaa