Hi Miklos,
thanks for the feedback. I think that having the prototype as shown below, would be very helpful from services point of view.
Best regards,
Antonio
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Miklos Balint via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 15 December 2018 15:39:12
To: tf-m(a)lists.trustedfirmware.org
Cc: nd
Subject: Re: [Tf-m] Uniform secure service signature proposal
To clarify: my suggestion is to update the signature to be identical to a RoT service call:
psa_status_t secure_function_name(struct psa_invec *in_vec, size_t in_len,
struct psa_outvec *out_vec, size_t out_len);
If that is accepted, I would update the proposal accordingly.
Thanks
/Miklos (wmnt)
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Miklos Balint via TF-M
Sent: 15 December 2018 16:33
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [Tf-m] Uniform secure service signature proposal
Hi Antonio,
Thanks for the comment. You are right, the return value of secure services should be explicitly typed to make its usage clear.
The thought process behind the current proposal was to provide a similar look-and-feel to the psa_call( ) function in the PSA Firmware Framework, i.e. to return something that is in line with psa_status_t since, as you mentioned, PSA services are already expected to provide a status code of type psa_status_t.
While the proposal failed to mention this, the restrictions present in TF-M currently for services with proprietary signatures would not apply to services with uniform signatures. So while at present services are expected to respect the reserved range of return values defined by TF-M, that would not be the case for services with uniform signatures. The analogy would be that the value provided to psa_reply() as a status code in the PSA Firmware Framework (described in version 1.0-beta-0 chapter 4.3.3 of that document) should be the return value from a secure service function with a "uniform signature" in my proposal.
Mate is working on some prototype code for this change in the return value to demonstrate. Let me know if this would work for you or if anyone has additional comments related to the topic/proposal.
Thanks
/Miklos (wmnt)
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: 12 December 2018 16:16
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [Tf-m] Uniform secure service signature proposal
Hi Miklos/Mate,
Thanks for the detailed proposal. I have a comment/question regarding the return type to be used in the unified signature.
int32_t secure_function_name(struct psa_invec *in_vec, size_t in_len,
struct psa_outvec *out_vec, size_t out_len);
The type returned is a int32_t. As a service developer, I have to be aware that although the type returned by the service is a int32_t, there is a set of reserved return codes which are reserved by the TF-M framework and can't be used freely by the service itself (as described in interface/include/tfm_api.h through the enum tfm_status_e type, only allowed values are below the TFM_PARTITION_SPECIFIC_ERROR_MIN). As a consequence, the services right now need to define their own return type and make sure the values don't clash with the values reserved by TF-M.
*Question is*: what is your opinion on explicitly marking the return type here with a dedicated type (instead of a plain int32_t) which enforces the fact that not all possible return values are usable by the service/secure function?
In addition to this, in case the feedback is positive, I think that the new type we choose/define should be aligned as much as possible with the patterns of the return types used by the service API's and this would help secure service developers. Currently in fact, as TF-M is reserving return values between 0x01 and 0x1F, an intermediate translation step is required, for everything different than TFM_SUCCESS, to align the values returned by services to the values that the API's return (take again in example the Crypto service which returns psa_status_t, when the return values are propagated back to the API interface, the TFM_PARTITION_SPECIFIC_ERROR_MIN needs to be removed every time). If we define our new type as to be still based on int32_t, but with TF-M reserved values in a very high range (e.g. between -0x1F and -0x1) this would save the translation step and won't clash with the return values that are defined by the services (or, at least, this seems to be the current trend).
Thanks in advance for any feedback on this observation.
Thanks,
Antonio
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi all,
Apologies. Opening a new thread for the new design proposal:
Please see the following link for a design proposal on IRQ handling by Secure Partitions in TF-M:
https://developer.trustedfirmware.org/w/tf_m/design/secure_partition_interr…
Any comments are welcome - preferably on this thread :)
Regards
/Miklos (wmnt)
Hi all,
Mate and myself have created a design proposal for uniform secure service signatures to provide more compatibility between PSA Firmware Framework and TF-M, to provide framework-level parameter sanitization for services and automatic non-secure callable veneer generation for the functions.
https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_…
Regards
/Miklos (wmnt)
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
To clarify: my suggestion is to update the signature to be identical to a RoT service call:
psa_status_t secure_function_name(struct psa_invec *in_vec, size_t in_len,
struct psa_outvec *out_vec, size_t out_len);
If that is accepted, I would update the proposal accordingly.
Thanks
/Miklos (wmnt)
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Miklos Balint via TF-M
Sent: 15 December 2018 16:33
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [Tf-m] Uniform secure service signature proposal
Hi Antonio,
Thanks for the comment. You are right, the return value of secure services should be explicitly typed to make its usage clear.
The thought process behind the current proposal was to provide a similar look-and-feel to the psa_call( ) function in the PSA Firmware Framework, i.e. to return something that is in line with psa_status_t since, as you mentioned, PSA services are already expected to provide a status code of type psa_status_t.
While the proposal failed to mention this, the restrictions present in TF-M currently for services with proprietary signatures would not apply to services with uniform signatures. So while at present services are expected to respect the reserved range of return values defined by TF-M, that would not be the case for services with uniform signatures. The analogy would be that the value provided to psa_reply() as a status code in the PSA Firmware Framework (described in version 1.0-beta-0 chapter 4.3.3 of that document) should be the return value from a secure service function with a "uniform signature" in my proposal.
Mate is working on some prototype code for this change in the return value to demonstrate. Let me know if this would work for you or if anyone has additional comments related to the topic/proposal.
Thanks
/Miklos (wmnt)
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: 12 December 2018 16:16
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [Tf-m] Uniform secure service signature proposal
Hi Miklos/Mate,
Thanks for the detailed proposal. I have a comment/question regarding the return type to be used in the unified signature.
int32_t secure_function_name(struct psa_invec *in_vec, size_t in_len,
struct psa_outvec *out_vec, size_t out_len);
The type returned is a int32_t. As a service developer, I have to be aware that although the type returned by the service is a int32_t, there is a set of reserved return codes which are reserved by the TF-M framework and can't be used freely by the service itself (as described in interface/include/tfm_api.h through the enum tfm_status_e type, only allowed values are below the TFM_PARTITION_SPECIFIC_ERROR_MIN). As a consequence, the services right now need to define their own return type and make sure the values don't clash with the values reserved by TF-M.
*Question is*: what is your opinion on explicitly marking the return type here with a dedicated type (instead of a plain int32_t) which enforces the fact that not all possible return values are usable by the service/secure function?
In addition to this, in case the feedback is positive, I think that the new type we choose/define should be aligned as much as possible with the patterns of the return types used by the service API's and this would help secure service developers. Currently in fact, as TF-M is reserving return values between 0x01 and 0x1F, an intermediate translation step is required, for everything different than TFM_SUCCESS, to align the values returned by services to the values that the API's return (take again in example the Crypto service which returns psa_status_t, when the return values are propagated back to the API interface, the TFM_PARTITION_SPECIFIC_ERROR_MIN needs to be removed every time). If we define our new type as to be still based on int32_t, but with TF-M reserved values in a very high range (e.g. between -0x1F and -0x1) this would save the translation step and won't clash with the return values that are defined by the services (or, at least, this seems to be the current trend).
Thanks in advance for any feedback on this observation.
Thanks,
Antonio
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Antonio,
Thanks for the comment. You are right, the return value of secure services should be explicitly typed to make its usage clear.
The thought process behind the current proposal was to provide a similar look-and-feel to the psa_call( ) function in the PSA Firmware Framework, i.e. to return something that is in line with psa_status_t since, as you mentioned, PSA services are already expected to provide a status code of type psa_status_t.
While the proposal failed to mention this, the restrictions present in TF-M currently for services with proprietary signatures would not apply to services with uniform signatures. So while at present services are expected to respect the reserved range of return values defined by TF-M, that would not be the case for services with uniform signatures. The analogy would be that the value provided to psa_reply() as a status code in the PSA Firmware Framework (described in version 1.0-beta-0 chapter 4.3.3 of that document) should be the return value from a secure service function with a "uniform signature" in my proposal.
Mate is working on some prototype code for this change in the return value to demonstrate. Let me know if this would work for you or if anyone has additional comments related to the topic/proposal.
Thanks
/Miklos (wmnt)
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: 12 December 2018 16:16
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [Tf-m] Uniform secure service signature proposal
Hi Miklos/Mate,
Thanks for the detailed proposal. I have a comment/question regarding the return type to be used in the unified signature.
int32_t secure_function_name(struct psa_invec *in_vec, size_t in_len,
struct psa_outvec *out_vec, size_t out_len);
The type returned is a int32_t. As a service developer, I have to be aware that although the type returned by the service is a int32_t, there is a set of reserved return codes which are reserved by the TF-M framework and can't be used freely by the service itself (as described in interface/include/tfm_api.h through the enum tfm_status_e type, only allowed values are below the TFM_PARTITION_SPECIFIC_ERROR_MIN). As a consequence, the services right now need to define their own return type and make sure the values don't clash with the values reserved by TF-M.
*Question is*: what is your opinion on explicitly marking the return type here with a dedicated type (instead of a plain int32_t) which enforces the fact that not all possible return values are usable by the service/secure function?
In addition to this, in case the feedback is positive, I think that the new type we choose/define should be aligned as much as possible with the patterns of the return types used by the service API's and this would help secure service developers. Currently in fact, as TF-M is reserving return values between 0x01 and 0x1F, an intermediate translation step is required, for everything different than TFM_SUCCESS, to align the values returned by services to the values that the API's return (take again in example the Crypto service which returns psa_status_t, when the return values are propagated back to the API interface, the TFM_PARTITION_SPECIFIC_ERROR_MIN needs to be removed every time). If we define our new type as to be still based on int32_t, but with TF-M reserved values in a very high range (e.g. between -0x1F and -0x1) this would save the translation step and won't clash with the return values that are defined by the services (or, at least, this seems to be the current trend).
Thanks in advance for any feedback on this observation.
Thanks,
Antonio
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Miklos/Mate,
Thanks for the detailed proposal. I have a comment/question regarding the return type to be used in the unified signature.
int32_t secure_function_name(struct psa_invec *in_vec, size_t in_len,
struct psa_outvec *out_vec, size_t out_len);
The type returned is a int32_t. As a service developer, I have to be aware that although the type returned by the service is a int32_t, there is a set of reserved return codes which are reserved by the TF-M framework and can't be used freely by the service itself (as described in interface/include/tfm_api.h through the enum tfm_status_e type, only allowed values are below the TFM_PARTITION_SPECIFIC_ERROR_MIN). As a consequence, the services right now need to define their own return type and make sure the values don't clash with the values reserved by TF-M.
*Question is*: what is your opinion on explicitly marking the return type here with a dedicated type (instead of a plain int32_t) which enforces the fact that not all possible return values are usable by the service/secure function?
In addition to this, in case the feedback is positive, I think that the new type we choose/define should be aligned as much as possible with the patterns of the return types used by the service API's and this would help secure service developers. Currently in fact, as TF-M is reserving return values between 0x01 and 0x1F, an intermediate translation step is required, for everything different than TFM_SUCCESS, to align the values returned by services to the values that the API's return (take again in example the Crypto service which returns psa_status_t, when the return values are propagated back to the API interface, the TFM_PARTITION_SPECIFIC_ERROR_MIN needs to be removed every time). If we define our new type as to be still based on int32_t, but with TF-M reserved values in a very high range (e.g. between -0x1F and -0x1) this would save the translation step and won't clash with the return values that are defined by the services (or, at least, this seems to be the current trend).
Thanks in advance for any feedback on this observation.
Thanks,
Antonio
