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
|
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.org>
Sent: 20 November 2024 22:49
To: tf-m@lists.trustedfirmware.org <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:
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