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