New PSA API proposal - TF-M

17 Feb 2019


      I obtained the following benchmarks for the 3 PSA APIs psa_connect(), psa_call(), and psa_close() using the attached implementation of a Secure Partition (my_sp.c) and building both my NS application and the SPE image with -O3 optimizations:
psa_connect()      2133 cycles
     psa_call()         2650 cycles
     psa_close()        2136 cycles
The psa_call() numbers were achieved by passing 'MY_SP_MSG_TYPE_NULL' as the message type to my test SP, thus eliminating any invec and outvec processing from the benchmark. The secure partition had been regenerated using the attached tfm manifest to reduce the number of user-provided SPs to just 2: the feature-ipc branch's test PSA service and my test PSA service.
With these benchmarks in mind and after reviewing the new PSA-compliant SST API implementations, I propose that a new, more efficient, PSA IPC API be provided for those user-facing SP service requests which require no state in the secure partition.
Below is the psa_sst_common() function shared by all of the new PSA compliant sst APIS (snipped from interface/src/tfm_sst_api_ipc.c):
static psa_status_t psa_sst_common(uint32_t sid, uint32_t minor_version,
                                   const psa_invec *in_vecs, size_t in_len,
                                   psa_outvec *out_vecs, size_t out_len)
 {
    psa_handle_t handle;
    psa_status_t status;
handle = psa_connect(sid, minor_version);
    if (handle <= 0) {
        return PSA_SST_ERR_PARAM_ERROR;
    }
status = psa_call(handle, in_vecs, in_len, out_vecs, out_len);
    if (status < 0) {
        status = PSA_SST_ERR_SYSTEM_ERROR;
    }
psa_close(handle);
    return status;
 }
I propose that the functionality and signature of 'psa_sst_common' be promoted to a formal PSA API. For lack of a better name, call this new API 'psa_ccc()', to convey the meaning that it combines the CONNECT, CALL, and CLOSE functions. Internally, the SPM would skip allocating and deallocating a handle, then pass message type 'PSA_IPC_CCC' to the SP.
Here is a crude representation of how the PSA_IPC_CCC message type could be handled by a Secure Partition:
case PSA_IPC_CCC:
            if (inuse) {
                psa_reply(msg.handle, PSA_CONNECTION_REFUSED);
            } else {
                inuse = 1;   /* to handle potential SP pre-emption during my_sp_call() case */
                r = my_sp_call(&msg);
                psa_reply(msg.handle, r);
                inuse = 0;
            }
            break;
Please consider this proposal. The new API would save the overhead of entering and exiting the SP 3 times for SP service requests that require no state.
Alan