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@01DB3B6B.1D4E93F0]
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
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:
[cid:image001.png@01DB3B6B.1D4E93F0]
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
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
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
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
Hi Nick,
The patches for attestation and crypto_init look good so I’ll test those soon. But check the response I just sent. If the underlying code of these services is strictly intended to be state-less only, then the existing code is okay as-is but a compile error should be raised if they are ever built for a connection-based service. But I think it’s preferable to explicitly unmap the input vectors so it could work for both stateless and connection-based.
Regards, Brian
From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Monday, December 2, 2024 3:31 PM To: Quach, Brian brian@ti.com; tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: [EXTERNAL] Re: connection-based MMIOVEC
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 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,
please find here a set of patches to address the issue you found: https://review.trustedfirmware.org/q/topic:%22mm-invec-unmap-crypto-att%22https://urldefense.com/v3/__https:/review.trustedfirmware.org/q/topic:*22mm-invec-unmap-crypto-att*22__;JSU!!G3vK!Q0SE2779ZMVxhCPLtwuqWlRFtP_m99IfqF1YkFW3RLOaZkrueeUuzQtKw8j_y-bxf6wb38p_EsYHcoiQpg$
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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 27 November 2024 15:35 To: Quach, Brian <brian@ti.commailto:brian@ti.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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.commailto:brian@ti.com> Sent: 21 November 2024 19:50 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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.commailto:Nicola.Mazzucato@arm.com> Sent: Thursday, November 21, 2024 6:37 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Cc: Quach, Brian <brian@ti.commailto: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@01DB44E0.53891F20]
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
Thanks Brian,
the patches I shared have been tested with a on-purpose modified Crypto interface and partition in order to handle stateful connections. The interface would connect and then psa-call more than once, then finally close. From my tests now it should be fixed. For stateless services the issue won't be noticed since the connection is handled by SPM behind the scenes.
Please note that the explicit unmapping of invecs is done for both Crypto and Attestation.
Hope that helps. Best regards, Nick
________________________________ From: Quach, Brian brian@ti.com Sent: 03 December 2024 00:33 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,
The patches for attestation and crypto_init look good so I’ll test those soon. But check the response I just sent. If the underlying code of these services is strictly intended to be state-less only, then the existing code is okay as-is but a compile error should be raised if they are ever built for a connection-based service. But I think it’s preferable to explicitly unmap the input vectors so it could work for both stateless and connection-based.
Regards, Brian
From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Monday, December 2, 2024 3:31 PM To: Quach, Brian brian@ti.com; tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: [EXTERNAL] Re: connection-based MMIOVEC
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
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,
please find here a set of patches to address the issue you found: https://review.trustedfirmware.org/q/topic:%22mm-invec-unmap-crypto-att%22https://urldefense.com/v3/__https:/review.trustedfirmware.org/q/topic:*22mm-invec-unmap-crypto-att*22__;JSU!!G3vK!Q0SE2779ZMVxhCPLtwuqWlRFtP_m99IfqF1YkFW3RLOaZkrueeUuzQtKw8j_y-bxf6wb38p_EsYHcoiQpg$
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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 27 November 2024 15:35 To: Quach, Brian <brian@ti.commailto:brian@ti.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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.commailto:brian@ti.com> Sent: 21 November 2024 19:50 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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.commailto:Nicola.Mazzucato@arm.com> Sent: Thursday, November 21, 2024 6:37 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Cc: Quach, Brian <brian@ti.commailto: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@01DB44E0.53891F20]
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
Hi Nick,
The patch set is working for me. Could you please integrate them into LTS?
Regards, Brian
From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Tuesday, December 3, 2024 2:04 AM To: Quach, Brian brian@ti.com; tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: [EXTERNAL] Re: connection-based MMIOVEC
Thanks Brian, the patches I shared have been tested with a on-purpose modified Crypto interface and partition in order to handle stateful connections. The interface would connect and then psa-call more than once, then finally close. From my 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 Thanks Brian,
the patches I shared have been tested with a on-purpose modified Crypto interface and partition in order to handle stateful connections. The interface would connect and then psa-call more than once, then finally close. From my tests now it should be fixed. For stateless services the issue won't be noticed since the connection is handled by SPM behind the scenes.
Please note that the explicit unmapping of invecs is done for both Crypto and Attestation.
Hope that helps. Best regards, Nick
________________________________ From: Quach, Brian <brian@ti.commailto:brian@ti.com> Sent: 03 December 2024 00:33 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto:nd@arm.com> Subject: RE: connection-based MMIOVEC
Hi Nick,
The patches for attestation and crypto_init look good so I’ll test those soon. But check the response I just sent. If the underlying code of these services is strictly intended to be state-less only, then the existing code is okay as-is but a compile error should be raised if they are ever built for a connection-based service. But I think it’s preferable to explicitly unmap the input vectors so it could work for both stateless and connection-based.
Regards, Brian
From: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com> Sent: Monday, December 2, 2024 3:31 PM To: Quach, Brian <brian@ti.commailto:brian@ti.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Subject: [EXTERNAL] Re: connection-based MMIOVEC
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
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,
please find here a set of patches to address the issue you found: https://review.trustedfirmware.org/q/topic:%22mm-invec-unmap-crypto-att%22https://urldefense.com/v3/__https:/review.trustedfirmware.org/q/topic:*22mm-invec-unmap-crypto-att*22__;JSU!!G3vK!Q0SE2779ZMVxhCPLtwuqWlRFtP_m99IfqF1YkFW3RLOaZkrueeUuzQtKw8j_y-bxf6wb38p_EsYHcoiQpg$
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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 27 November 2024 15:35 To: Quach, Brian <brian@ti.commailto:brian@ti.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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.commailto:brian@ti.com> Sent: 21 November 2024 19:50 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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.commailto:Nicola.Mazzucato@arm.com> Sent: Thursday, November 21, 2024 6:37 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Cc: Quach, Brian <brian@ti.commailto: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@01DB44E0.53891F20]
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
Good news, thanks Brian!
Certainly can. Could you kindly open an issue in github (https://github.com/TrustedFirmware-M/trusted-firmware-m/issues), as this is the official way to deal with such things. That will help us all with the future tracking and reference.
Many thanks in advance Best regards
Nick ________________________________ From: Quach, Brian brian@ti.com Sent: 03 December 2024 20:21 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,
The patch set is working for me. Could you please integrate them into LTS?
Regards, Brian
From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Tuesday, December 3, 2024 2:04 AM To: Quach, Brian brian@ti.com; tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: [EXTERNAL] Re: connection-based MMIOVEC
Thanks Brian, the patches I shared have been tested with a on-purpose modified Crypto interface and partition in order to handle stateful connections. The interface would connect and then psa-call more than once, then finally close. From my
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
Thanks Brian,
the patches I shared have been tested with a on-purpose modified Crypto interface and partition in order to handle stateful connections. The interface would connect and then psa-call more than once, then finally close.
From my tests now it should be fixed.
For stateless services the issue won't be noticed since the connection is handled by SPM behind the scenes.
Please note that the explicit unmapping of invecs is done for both Crypto and Attestation.
Hope that helps.
Best regards,
Nick
________________________________
From: Quach, Brian <brian@ti.commailto:brian@ti.com> Sent: 03 December 2024 00:33 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto:nd@arm.com> Subject: RE: connection-based MMIOVEC
Hi Nick,
The patches for attestation and crypto_init look good so I’ll test those soon. But check the response I just sent. If the underlying code of these services is strictly intended to be state-less only, then the existing code is okay as-is but a compile error should be raised if they are ever built for a connection-based service. But I think it’s preferable to explicitly unmap the input vectors so it could work for both stateless and connection-based.
Regards, Brian
From: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com> Sent: Monday, December 2, 2024 3:31 PM To: Quach, Brian <brian@ti.commailto:brian@ti.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Subject: [EXTERNAL] Re: connection-based MMIOVEC
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
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,
please find here a set of patches to address the issue you found: https://review.trustedfirmware.org/q/topic:%22mm-invec-unmap-crypto-att%22https://urldefense.com/v3/__https:/review.trustedfirmware.org/q/topic:*22mm-invec-unmap-crypto-att*22__;JSU!!G3vK!Q0SE2779ZMVxhCPLtwuqWlRFtP_m99IfqF1YkFW3RLOaZkrueeUuzQtKw8j_y-bxf6wb38p_EsYHcoiQpg$
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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 27 November 2024 15:35 To: Quach, Brian <brian@ti.commailto:brian@ti.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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.commailto:brian@ti.com> Sent: 21 November 2024 19:50 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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.commailto:Nicola.Mazzucato@arm.com> Sent: Thursday, November 21, 2024 6:37 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Cc: Quach, Brian <brian@ti.commailto: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@01DB44E0.53891F20]
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
Hi Nick,
Sure. See https://github.com/TrustedFirmware-M/trusted-firmware-m/issues/19
Regards, Brian
From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Thursday, December 5, 2024 6:09 AM To: Quach, Brian brian@ti.com; tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: [EXTERNAL] Re: connection-based MMIOVEC
Good news, thanks Brian! Certainly can. Could you kindly open an issue in github (https: //github. com/TrustedFirmware-M/trusted-firmware-m/issues), as this is the official way to deal with such things. That will help us all with the future tracking 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 Good news, thanks Brian!
Certainly can. Could you kindly open an issue in github (https://github.com/TrustedFirmware-M/trusted-firmware-m/issueshttps://urldefense.com/v3/__https:/github.com/TrustedFirmware-M/trusted-firmware-m/issues__;!!G3vK!XwLubAd9bNUrn8WSHen_OjtS1s7-WOApkMRXLAyyRREfX130YEU8oilS7mBNZvCDmVxzOxXwRBE-G96wLg$), as this is the official way to deal with such things. That will help us all with the future tracking and reference.
Many thanks in advance Best regards
Nick ________________________________ From: Quach, Brian <brian@ti.commailto:brian@ti.com> Sent: 03 December 2024 20:21 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto:nd@arm.com> Subject: RE: connection-based MMIOVEC
Hi Nick,
The patch set is working for me. Could you please integrate them into LTS?
Regards, Brian
From: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com> Sent: Tuesday, December 3, 2024 2:04 AM To: Quach, Brian <brian@ti.commailto:brian@ti.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Subject: [EXTERNAL] Re: connection-based MMIOVEC
Thanks Brian, the patches I shared have been tested with a on-purpose modified Crypto interface and partition in order to handle stateful connections. The interface would connect and then psa-call more than once, then finally close. From my
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
Thanks Brian,
the patches I shared have been tested with a on-purpose modified Crypto interface and partition in order to handle stateful connections. The interface would connect and then psa-call more than once, then finally close.
From my tests now it should be fixed.
For stateless services the issue won't be noticed since the connection is handled by SPM behind the scenes.
Please note that the explicit unmapping of invecs is done for both Crypto and Attestation.
Hope that helps.
Best regards,
Nick
________________________________
From: Quach, Brian <brian@ti.commailto:brian@ti.com> Sent: 03 December 2024 00:33 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto:nd@arm.com> Subject: RE: connection-based MMIOVEC
Hi Nick,
The patches for attestation and crypto_init look good so I’ll test those soon. But check the response I just sent. If the underlying code of these services is strictly intended to be state-less only, then the existing code is okay as-is but a compile error should be raised if they are ever built for a connection-based service. But I think it’s preferable to explicitly unmap the input vectors so it could work for both stateless and connection-based.
Regards, Brian
From: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com> Sent: Monday, December 2, 2024 3:31 PM To: Quach, Brian <brian@ti.commailto:brian@ti.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Subject: [EXTERNAL] Re: connection-based MMIOVEC
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
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,
please find here a set of patches to address the issue you found: https://review.trustedfirmware.org/q/topic:%22mm-invec-unmap-crypto-att%22https://urldefense.com/v3/__https:/review.trustedfirmware.org/q/topic:*22mm-invec-unmap-crypto-att*22__;JSU!!G3vK!Q0SE2779ZMVxhCPLtwuqWlRFtP_m99IfqF1YkFW3RLOaZkrueeUuzQtKw8j_y-bxf6wb38p_EsYHcoiQpg$
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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 27 November 2024 15:35 To: Quach, Brian <brian@ti.commailto:brian@ti.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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.commailto:brian@ti.com> Sent: 21 November 2024 19:50 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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.commailto:Nicola.Mazzucato@arm.com> Sent: Thursday, November 21, 2024 6:37 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Cc: Quach, Brian <brian@ti.commailto: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@01DB44E0.53891F20]
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
Hi Nick,
I’m using v2.0 mainline, but in a non-standard way. I’ve implemented a custom connection-based crypto service which reuses the out-of-box tfm_crypto_call_srv() function which I have exposed by removing the ‘static’ keyword. If that function was only designed to work with state-less connections, then there is no issue because spm_init_connection() handles clearing of iovec_status for every PSA call and outvecs are unmapped before calling psa_write().
It sounds like connection-based services supporting MM_IOVECS require that invecs + outvecs are unmapped by the service before returning. Otherwise, the connection must be closed and re-opened for every PSA call to that service. PSA FF v1.1 extensions say “If psa_unmap_invec() is not called for an input vector that has been mapped, the framework will remove the mapping automatically when the message is completed.” But it’s not clear to me whether “framework” means the SPM or the service itself.
Could you confirm how MM_IOVEC input vector unmapping should be handled for connection-based services in the TFM?
Regards, Brian
From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Wednesday, November 27, 2024 9:36 AM To: Quach, Brian brian@ti.com; tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: [EXTERNAL] 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 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 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.commailto:brian@ti.com> Sent: 21 November 2024 19:50 To: Nicola Mazzucato <Nicola.Mazzucato@arm.commailto:Nicola.Mazzucato@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto: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
tf-m@lists.trustedfirmware.org
-
Nicola Mazzucato -
Quach, Brian