Page MenuHomePhabricator

Uniform Secure Service Signature Alignment
Updated 2,087 Days AgoPublic

Table of contents

  • Scope
  • Terms and abbreviations
  • References
  • Introduction
  • Design content
    • SST service components
    • SST request Manager
    • SST Manifest file
    • TF-M error codes
    • PSA PS APIs non-secure and secure implementation
  • Validation tests

Scope

The scope of this document is to describe the SST secure service design to align it with the uniform secure service signatures.

Terms and abbreviations

This document uses the following terms and abbreviations.

TermMeaning
APIApplication Program Interface
PSProtected Storage
PSAPlatform Security Architecture
PPSPSA Protected Storage
SSTSecure Storage Service
TF-MTrusted Firmware for M-class devices

References

Introduction

Currently, a <service_name>_veneers.c file is created in the secure_fw/ns_callable directory, that specifies the signature for each veneer function, and calls the secure function from the veneers.
The respective interface/include/<service_name>_veneers.h file with the veneer declarations is created and maintained manually. In addition, the TF-M framework, aligned with that design, limits the range of valid return values a secure service can provide, reserving a range for framework error codes.

The uniform secure service signature design [ 1 ] proposes to use a uniform signature for all the secure functions of the secure service. There are multiple advantages of this method:

  • TF-M Core can do a sanity check on the access rights of the veneer parameters, and there is no need for the secure services to make these checks individually. Please note that in the present implementation sanity check is only fully supported for level 1 isolation.
  • The veneer declarations and implementations for the secure functions can be generated automatically from a template (using the secure function list in the secure service's manifest)

The signature for such secure services would look like this:

psa_status_t secure_function_name(struct psa_invec *in_vec, size_t in_len,
                                  struct psa_outvec *out_vec, size_t out_len);

A detailed information about the signature can be found in [ 1 ].

Design Content

SST service components

The current SST service implements a set of components, each one dedicated to implementing a specific functionality in each layer of the SST service firmware stack [ 2 ][ 3 ].

The set of functionalities are:

  • Protected Storage layer: This layer exposes the PSA protected storage set of interfaces which are compliant with the PPS APIs specification.
  • Object System: This component contains the object system implementation to manage all objects stored in the SST area.
  • File System: It abstracts the flash filesystem operations for the secure storage service. The purpose of this abstraction is to have the ability to plug-in other filesystems or filesystem proxies (supplicant). Currently, it implements a custom filesystem based on a non-hierarchical storage model where all the files are managed by linearly indexed list of metadata.

The current SST firmware stack is:

The new design adds the SST request manager layer as the entry point to the service. This layer manages all requests which arrive to the service, and performs the proper Protected Storage calls. Detailed information about this layer can be found in the section below.

The new SST firmware layers are:

SST request Manager

The SST request manager handles all requests which arrive to the service. The interfaces of this layer are aligned with the unified secure service signatures. This layer extracts the arguments from the input and output vectors, and it calls the protected storage layer with the provided parameters. It also checks that the number of parameters and sizes are aligned with the protected storage interface to call.

The list of interfaces exposed by the SST request manager layer are:

tfm_sst_set_req()

This function handles the PSA PS set requests.

psa_status_t tfm_sst_set_req(struct psa_invec *in_vec, size_t in_len,
                             struct psa_outvec *out_vec, size_t out_len);

Parameters

DirectionTypeNameDescription
instruct psa_invec *in_vecPointer to the input vector which contains the input parameters.
insize_tin_lenNumber of input parameters in the input vector.
outstruct psa_invec *out_vecPointer to the output vector which contains the output parameters.
insize_tout_lenNumber of output parameters in the output vector.

Return
A status indicating the success/failure of the operation as specified in psa_status_t.

TypeDescription
PSA_SUCCESSThe operation completed successfully.
PSA_CONNECTION_REFUSEDThe operation is refused because the number of input or output parameters in the vectors are incorrect or their types are incorrect.

The following table shows the input parameters mapping in the in_vec vector.

PSA IN_VEC ElementSST PS Layer Set Function Input Parameter Names
in_vec[0].base = &uid; in_vec[0].len = sizeof(uid);psa_ps_uid_t uid
in_vec[1].base = p_data; in_vec[1].len = data_length;const void *p_data and uint32_t data_length
in_vec[2].base = &create_flags; in_vec[2].len = sizeof(create_flags);psa_ps_create_flags_t create_flags

The following table shows the input parameters mapping in the out_vec vector.

PSA OUT_VEC ElementSST PS Layer Set Function Output/Return Parameter Name
out_vec[0].base = &err; out_vec[0].len = sizeof(err);psa_ps_status_t err defined in the caller space

tfm_sst_get_req()

This function handles the PSA PS get requests.

psa_status_t tfm_sst_get_req(struct psa_invec *in_vec, size_t in_len,
                             struct psa_outvec *out_vec, size_t out_len);

Parameters

DirectionTypeNameDescription
instruct psa_invec *in_vecPointer to the input vector which contains the input parameters.
insize_tin_lenNumber of input parameters in the input vector.
outstruct psa_invec *out_vecPointer to the output vector which contains the output parameters.
insize_tout_lenNumber of output parameters in the output vector.

Return
A status indicating the success/failure of the operation as specified in psa_status_t.

TypeDescription
PSA_SUCCESSThe operation completed successfully.
PSA_CONNECTION_REFUSEDThe operation is refused because the number of input or output parameters in the vectors are incorrect or their types are incorrect.

The following table shows the input parameters mapping in the in_vec vector.

PSA IN_VEC ElementSST PS Layer Get Function Input Parameter Names
in_vec[0].base = &uid; in_vec[0].len = sizeof(uid);psa_ps_uid_t uid
in_vec[1].base = &data_offset; in_vec[1].len = sizeof(data_offset);uint32_t data_offset

The following table shows the input parameters mapping in the out_vec vector.

PSA OUT_VEC ElementSST PS Layer Get Function Output/Return Parameter Names
out_vec[0].base = &err; out_vec[0].len = sizeof(err);psa_ps_status_t err defined in the caller space
out_vec[1].base = p_data; out_vec[1].len = data_length;const void *p_data and uint32_t data_length

tfm_sst_get_info_req()

This function handles the PSA PS get info requests.

psa_status_t tfm_sst_get_info_req(struct psa_invec *in_vec, size_t in_len,
                                  struct psa_outvec *out_vec, size_t out_len);

Parameters

DirectionTypeNameDescription
instruct psa_invec *in_vecPointer to the input vector which contains the input parameters.
insize_tin_lenNumber of input parameters in the input vector.
outstruct psa_invec *out_vecPointer to the output vector which contains the output parameters.
insize_tout_lenNumber of output parameters in the output vector.

Return
A status indicating the success/failure of the operation as specified in psa_status_t.

TypeDescription
PSA_SUCCESSThe operation completed successfully.
PSA_CONNECTION_REFUSEDThe operation is refused because the number of input or output parameters in the vectors are incorrect or their types are incorrect.

The following table shows the input parameters mapping in the in_vec vector.

PSA IN_VEC ElementSST PS Layer Get Info Function Input Parameter Name
in_vec[0].base = &uid; in_vec[0].len = sizeof(uid);psa_ps_uid_t uid

The following table shows the input parameters mapping in the out_vec vector.

PSA OUT_VEC ElementSST PS Layer Get Info Function Output/Return Parameter Names
out_vec[0].base = &err; out_vec[0].len = sizeof(err);psa_ps_status_t err defined in the caller space
out_vec[1].base = p_info; out_vec[1].len = sizeof(*p_info);struct psa_ps_info_t *p_info

tfm_sst_remove_req()

This function handles the PSA PS remove requests.

psa_status_t tfm_sst_remove_req(struct psa_invec *in_vec, size_t in_len,
                                struct psa_outvec *out_vec, size_t out_len);

Parameters

DirectionTypeNameDescription
instruct psa_invec *in_vecPointer to the input vector which contains the input parameters.
insize_tin_lenNumber of input parameters in the input vector.
outstruct psa_invec *out_vecPointer to the output vector which contains the output parameters.
insize_tout_lenNumber of output parameters in the output vector.

Return
A status indicating the success/failure of the operation as specified in psa_status_t.

TypeDescription
PSA_SUCCESSThe operation completed successfully.
PSA_CONNECTION_REFUSEDThe operation is refused because the number of input or output parameters in the vectors are incorrect or their types are incorrect.

The following table shows the input parameters mapping in the in_vec vector.

PSA IN_VEC ElementSST PS Layer Remove Function Input Parameter Name
in_vec[0].base = &uid; in_vec[0].len = sizeof(uid);psa_ps_uid_t uid

The following table shows the input parameters mapping in the out_vec vector.

PSA OUT_VEC ElementSST PS Layer Remove Function Output/Return Parameter Name
out_vec[0].base = &err; out_vec[0].len = sizeof(err);psa_ps_status_t err defined in the caller space

tfm_sst_get_support_req()

This function handles the PSA PS get support requests.

psa_status_t tfm_sst_get_support_req(struct psa_invec *in_vec, size_t in_len,
                                     struct psa_outvec *out_vec, size_t out_len);

Parameters

DirectionTypeNameDescription
instruct psa_invec *in_vecPointer to the input vector which contains the input parameters.
insize_tin_lenNumber of input parameters in the input vector.
outstruct psa_invec *out_vecPointer to the output vector which contains the output parameters.
insize_tout_lenNumber of output parameters in the output vector.

Return
A status indicating the success/failure of the operation as specified in psa_status_t.

TypeDescription
PSA_SUCCESSThe operation completed successfully.
PSA_CONNECTION_REFUSEDThe operation is refused because the number of input or output parameters in the vectors are incorrect or their types are incorrect.

The following table shows the input parameters mapping in the in_vec vector.

PSA IN_VEC ElementSST PS Layer Get Support Function Input Parameter Name
NONENONE

The following table shows the input parameters mapping in the out_vec vector.

PSA OUT_VEC ElementSST PS Layer Get Support Function Output/Return Parameter Name
out_vec[0].base = &support_flags; out_vec[0].len = sizeof(support_flags);uint32_t support_flags

SST Manifest file

The SST manifest file must be updated to expose the SST request manager functions rather than the Protected Storage layer. However, the “tfm_init_symbol” entry needs to be tfm_sst_init as this is the function which initializes the service.
The “source_file” list must be updated to add the new SST request manager files.

TF-M error codes

The legacy TF-M framework, used by the current SST implementation, limits the range of valid return values that a secure service can provide, reserving a range for framework error codes. For that reason, the TF-M SST codes need to be different from the PSA PS ones. The uniform secure service feature in TF-M framework does not have this requirement anymore, so the current TF-M SST error codes must be replaced by the PSA PS ones [ 4 ].

PSA PS APIs non-secure and secure implementation

The current implementation must be updated to evaluate psa_status_t return codes from TF-M framework. In case, TF-M framework returns a value different from PSA_SUCCESS, the interface should return a PSA_PS_ERROR_OPERATION_FAILED as a PSA PS error code. Otherwise, it should return the error code returned via out_vec.

Each PSA PS API implementation must map the input, output and return vales as defined in section "SST request Manager" per each request interface.

Validation Tests

To validate the new design of SST service, the new version must pass all the SST test suites defined in TF-M and
PSA Arch tests [ 5 ].

However, the psa_ps_ns_interface and psa_ps_s_interface test suites must be updated to modify the tests which check the validity of the callers memory referenced by a pointer. All the null pointer checks must be with data length equal to 0. The new TF-M framework incorporates a mechanism to check the validity of the memory area referred by the pointers plus data length [ 1 ]. If secure partition requests a service with an invalid pointer with a data length different from 0, in one or more parameters, the TF-M frameworks returns a specific error code to reject the request. In the other hand, if a non-secure application requests a service with a null pointer with a data length different from 0, in one or more parameters, the TF-M framework blocks the request and it does not return the control to the non-secure application.

Last Author
mmorenobarm
Last Edited
Feb 18 2019, 2:38 PM

Event Timeline

mmorenobarm created this document.Feb 7 2019, 6:00 PM
mmorenobarm edited the content of this document. (Show Details)
mmorenobarm added a project: Restricted Project.
mmorenobarm edited the content of this document. (Show Details)Feb 18 2019, 2:38 PM