Hi Brian,
please find here a set of patches to address the issue you found: https://review.trustedfirmware.org/q/topic:%22mm-invec-unmap-crypto-att%22
Would appreciate if you can test those in your environment and let us know the results and/or further suggestions.
In addition, please let us know if you wish to integrate the above fixes in the LTS branch.
Everybody else is, as always, more than welcome to provide suggestions.
Many thanks in advance Best regards,
Nick
________________________________ From: Nicola Mazzucato via TF-M tf-m@lists.trustedfirmware.org Sent: 27 November 2024 15:35 To: Quach, Brian brian@ti.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: [TF-M] Re: connection-based MMIOVEC
Hi Brian,
many thanks for your reply. I managed to do a quick test and what you noticed makes sense to me.
It looks however that the current crypto service does not support connection-based operations, so my tests were limited to stateless calls so far. Are you based on a different branch from mainline? Do you use a different crypto interface from the one available upstream?
Best regards, Thanks
Nick
________________________________ From: Quach, Brian brian@ti.com Sent: 21 November 2024 19:50 To: Nicola Mazzucato Nicola.Mazzucato@arm.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: RE: connection-based MMIOVEC
Hi Nick,
I’m using medium profile but with PSA_FRAMEWORK_HAS_MM_IOVEC enabled.
In the partition yaml file:
"model": "IPC",
"services" : [
"connection_based": true,
"mm_iovec": "enable"
]
After psa_connect, the second psa_call using MM IOVECS to the partition should fail.
It’s fairly easy to look at the code snippets I sent and see the input vectors are not being unmapped. Was this done on purpose or was it overlooked? I would think if the outputs are being unmapped, that inputs should be as well.
Regards, Brian
From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Thursday, November 21, 2024 6:37 AM To: tf-m@lists.trustedfirmware.org; nd nd@arm.com Cc: Quach, Brian brian@ti.com Subject: [EXTERNAL] Re: connection-based MMIOVEC
Hi Brian, many thanks for reporting this. I shall take a look and attempt to reproduce it and will share my findings. In the meantime, could you please share your build commands? Many thanks Best regards, Nick From: Quach, Brian via TF-M <tf-m@ lists. trustedfirmware. org>
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.
ZjQcmQRYFpfptBannerEnd
Hi Brian,
many thanks for reporting this.
I shall take a look and attempt to reproduce it and will share my findings.
In the meantime, could you please share your build commands?
Many thanks
Best regards,
Nick
________________________________
From: Quach, Brian via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 20 November 2024 22:49 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] connection-based MMIOVEC
Hi,
I am trying to use connection-based (instead of SFN) Crypto service with MMIOVEC, but I noticed that iovec_status is not automatically cleared so the second psa_call causes a TFM panic due to detection of a previously mapped IOVEC.
FF spec says:
[cid:image001.png@01DB3C1C.2677FC30]
In tfm_crypto_call_srv(), I see the output vecs are unmapped but not the input vectors. Should the inputs be unmapped here as well? (psa_attest_get_token also does not unmap input vecs)
status = tfm_crypto_init_iovecs(msg, in_vec, in_len, out_vec, out_len);
if (status != PSA_SUCCESS) {
return status;
}
tfm_crypto_set_caller_id(msg->client_id);
/* Call the dispatcher to the functions that implement the PSA Crypto API */
status = tfm_crypto_api_dispatcher(in_vec, in_len, out_vec, out_len);
#if PSA_FRAMEWORK_HAS_MM_IOVEC == 1
for (i = 0; i < out_len; i++) {
if (out_vec[i].base != NULL) {
psa_unmap_outvec(msg->handle, i, out_vec[i].len);
}
}
#else
/* Write into the IPC framework outputs from the scratch */
for (i = 0; i < out_len; i++) {
psa_write(msg->handle, i, out_vec[i].base, out_vec[i].len);
}
Currently, to clear the connection’s iovec_status, I have to call psa_close() after every psa_call() and reconnect with psa_connect() before the next psa_call() which adds overhead. Is this behavior of not automatically clearing iovec_status for connection-based services by design?
As an alternative to calling psa_unmap_invecs(), I was wondering if spm_get_connection()/spm_get_idle_connection() could be modified with the following workaround to avoid needing to close/connect:
#if CONFIG_TFM_CONNECTION_BASED_SERVICE_API == 1
connection = handle_to_connection(handle);
if (!connection) {
return PSA_ERROR_PROGRAMMER_ERROR;
}
if (spm_validate_connection(connection) != PSA_SUCCESS) {
return PSA_ERROR_PROGRAMMER_ERROR;
}
/* WORKAROUND */
#if PSA_FRAMEWORK_HAS_MM_IOVEC
connection->iovec_status &= 0xFFFF0000; // Clear status of input vecs
#endif
/* Validate the caller id in the connection handle equals client_id. */
if (connection->msg.client_id != client_id) {
return PSA_ERROR_PROGRAMMER_ERROR;
}
/*
* It is a PROGRAMMER ERROR if the connection is currently
* handling a request.
*/
if (connection->status != TFM_HANDLE_STATUS_IDLE) {
return PSA_ERROR_PROGRAMMER_ERROR;
}
if (!(connection->service)) {
/* FixMe: Need to implement a mechanism to resolve this failure. */
return PSA_ERROR_PROGRAMMER_ERROR;
}
#else
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
