Hide generated veneer format from its users by using wrapper macro
Open, NormalPublic

Description

At present veneers generated for uniform secure service signatures are each pre- and postfixed individually in the corresponding header file: interface/include/tfm_veneers.h

Hide this "transport layer" naming convention by providing a MACRO that takes the secure service function name and substitutes the generated veneer name. This MACRO could then be used in the header file for individual function signatures as well as for abstraction layer wrappers corresponding to secure service functions, and would hide TF-M-internal naming convention from service owners and eliminate some dependencies.
Wrappers would invoke the macro with their respective secure service function names, which would in turn be replaced compile-time with the appropriate veneer name.

A proposed definition in line with Uniform Secure Service Signature naming would be
#define TFM_VENEER_NAME(secure_function_name) tfm_##secure_function_name##_veneer

This macro would eliminate confusion and inconveniences with pre- and postfixes needed when invoking uniform signature veneers.

wmnt created this task.Jan 10 2019, 1:20 PM
wmnt triaged this task as Normal priority.

Hi Miklos, this proposal looks good to me, another good point about it is that using a macro would encapsulate the veneer layer and make sure that any change in the naming convention under the hood of the macro will not need to be reflected in callers of the veneers.

One clarification is: how would a call to the veneers would look like? something like TFM_VENEER_NAME(secure_function_name)( <parameters> ) ? Do you think another macro which groups the parameters of the call would help here? I

wmnt assigned this task to matetothpal.Jul 25 2019, 5:34 PM

Revisiting this topic:

Antonio (@adeaarm),
Thanks for the comment. I was thinking about a calling convention that relies on this pattern, yes. I agree using only this macro would feel inadequate.

Mate (@matetothpal),
Could you check if this item still has relevance or if the complexities with its introduction outweight the benefits?

Thanks
Miklos