psa_call(...) prototype in the veneer function uses wrong parameters
Open, LowPublic

Description

This has been raised by Alan on the mailing list:

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> on behalf of DeMars, Alan via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 10 April 2019 22:12
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer?

It seems to me that the 'psa_invec' type is incorrectly being used where the 'psa_outvec' type should be used everywhere tfm_psa_call_veneer() is used.

In tfm_api.h, I think this:

psa_status_t tfm_psa_call_veneer(psa_handle_t handle,

const psa_invec *in_vecs,
 
const psa_invec *out_vecs);

should be this:

psa_status_t tfm_psa_call_veneer(psa_handle_t handle,

const psa_invec *in_vecs,
 
const psa_outvec *out_vecs);

And, in the implementation of the tfm_psa_call_veneer

within tfm_psa_api_client.c, I think this:

tfm_secure_gateway_attributes

psa_status_t tfm_psa_call_veneer(psa_handle_t handle,

const psa_invec *in_vecs,
 
const psa_invec *out_vecs)

should be this:

tfm_secure_gateway_attributes

psa_status_t tfm_psa_call_veneer(psa_handle_t handle,

const psa_invec *in_vecs,
 
const psa_outvec *out_vecs)

And, in the NS implementation of psa_call() within tfm_psa_ns_api.c, I think this:

psa_invec in_vecs, out_vecs;

should be this:

psa_invec in_vecs;
 
psa_outvec out_vecs;

Also, psa_outvec should drop the const qualifier as it's an output parameter that needs to be non-const.

adeaarm created this task.Wed, Apr 10, 10:29 PM
adeaarm triaged this task as Normal priority.
wmnt added a subscriber: wmnt.Thu, Apr 11, 7:56 AM

The transition from NS to S using the psa_call veneer has an implementation-defined layer of serialization in addition to what is prescribed in the PSA client API, necessary because of the limitations on parameter passing between security states.
The argument list mentioned above:

psa_status_t tfm_psa_call_veneer(psa_handle_t handle,
        const psa_invec *in_vecs,
        const psa_invec *out_vecs);

has those data types by design: both the invec array and outvec array are serialized to one invec each, i.e. two input parameters for the secure veneer, one containing the array of invecs, the other containing the array of outvecs.
From the veneer point of view both are constant input parameters, hence the const psa_invec type.
When extracting the arrays from these vectors in tfm_svcalls.c you can see the deserialization to the PSA-defined data types:

outptr = (psa_outvec *)((psa_invec *)args[2])->base;
out_num = ((psa_invec *)args[2])->len;

Got it, thanks for the clarification. Do you think it's worth it to add a comment in the code to explain this in the header? Might be confusing at first glance. Or we should just close this item as a "won't fix, not an issue."

This issue is related to a further design change of retrieve NS parameters; let me down the priority for it and keep it here as a reminder.

KenLSoft lowered the priority of this task from Normal to Low.Fri, Apr 12, 2:31 AM
adeaarm reassigned this task from adeaarm to KenLSoft.Sat, Apr 13, 12:19 AM

Assigned to Ken as he's the one driving this activity.