- TF-M - lists.trustedfirmware.org

How to run PSA API compliance tests with TF-M Crypto

by Antonio De Angelis

Hi all, It's possible to run a subset of the PSA API Compliance tests with the TF-M Crypto service by following the instructions below (it assumes that psa-arch-tests and trusted-firmware-m directories are at the same level in the filesystem): 1. Checkout https://github.com/ARM-software/psa-arch-tests/tree/ew_beta0 (ew_beta0 branch of the PSA API Compliance tests repo) 2. Checkout https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/561/ 3. Copy the interface/include/psa_crypto.h to interface/include/psa/crypto.h as this is the header name expected by the PSA API Compliance tests 4. Build the Crypto tests for the PSA API compliance as described in the psa-arch-tests/api-tests for one of the supported targets, providing the include path of the TF-M interface (i.e. trusted-firmware-m/interface/include) * The list of tests being run is specified in the file psa-arch-tests/api-tests/dev_apis/crypto/testsuite.db * For example, this command will build the tests for AN521 "./tools/scripts/setup.sh --target tgt_dev_apis_tfm_an521 --toolchain ARMCLANG --cpu_arch armv8m_ml --verbose 2 --suite crypto --include ../../trusted-firmware-m/interface/include --archive_tests" 5. Build TF-M by using the ConfigPsaApiTest.cmake, enabling the PSA API Compliance tests for Crypto by adding the following cmake switch during the configuration step: "-DPSA_API_TEST_CRYPTO=ON" * For example, this command will build the TF-M + NS app with PSA API Crypto tests for AN521 "cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../ConfigPsaApiTest.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=ARMCLANG -DPSA_API_TEST_CRYPTO=ON ../" This will make our NS test app run a subset of the PSA API compliance tests for Crypto. We are currently working on fixing the remaining failures. Thanks, Antonio

7 years, 1 month

1
1
0 0

IPC patches merged into branch 'feature-ipc'

by Ken Liu (Arm Technology China)

Hi Subscribers, Group of IPC patches has been merged into branch 'feature-ipc'. The features are: * PSA Firmware Framework API (based on scheduler and message queue) and example partitions. * Isolation level 1 * Verified on AN521 You can find the design link here: https://developer.trustedfirmware.org/w/tf_m/design/ipc_design/ Some issues are identified and need to be solved. We will publish the list of improvements soon. Any feedback please mail to tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> You can also create questions and issues at https://developer.trustedfirmware.org Thanks. -Ken

7 years, 1 month

1
0
0 0

Re: [Tf-m] Replace custom code generating scripts with Jinja2

by Ken Liu (Arm Technology China)

Hi Mate, Thanks for the proposal. It looks nice. I have read the "Improvements over the current solution" part and I think the "More advanced functionality" is the point I am interested in. There are some necessary jobs to be done in the code generating scripts for IPC; hope using this tool could help on that. One thing we are investigating is: * We need to put PSA RoT and APP RoT into different groups in linker script; current tool just put all partitions together and ignores partition type. Can you help to check if the new tool could make this change easier? Thanks. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Mate Toth-Pal via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, January 21, 2019 8:37:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [Tf-m] Replace custom code generating scripts with Jinja2 Hi All, Based on the design proposal published here: https://developer.trustedfirmware.org/w/tf_m/design/code_generation_with_ji… I am planning to replace the code generation tool currently used in the TF-M with the Jinja2 template engine. I already prepared the change that implements this. It is available for review and testing in this gerrit review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/507/ Please note, that this introduces a new tool dependency: jinja2 v2.10 python library have to be installed to generate code from the partition manifests. Earlier than 2.10 versions won't work, as one of the templates relies on the namespace feature introduced in this version. Based on this change I also would like to make the secure sct files automatically generated (just like the secure ld files). The gerrit review for this change is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ Should you have any questions, suggestions, objections, please do not hesitate to contact! Thanks, Mate -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 1 month

1
1
0 0

Replace custom code generating scripts with Jinja2

by Mate Toth-Pal

Hi All, Based on the design proposal published here: https://developer.trustedfirmware.org/w/tf_m/design/code_generation_with_ji… I am planning to replace the code generation tool currently used in the TF-M with the Jinja2 template engine. I already prepared the change that implements this. It is available for review and testing in this gerrit review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/507/ Please note, that this introduces a new tool dependency: jinja2 v2.10 python library have to be installed to generate code from the partition manifests. Earlier than 2.10 versions won't work, as one of the templates relies on the namespace feature introduced in this version. Based on this change I also would like to make the secure sct files automatically generated (just like the secure ld files). The gerrit review for this change is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ Should you have any questions, suggestions, objections, please do not hesitate to contact! Thanks, Mate

7 years, 1 month

1
0
0 0

Re: [Tf-m] ARM.TFM CMSIS pack questions

by Darshpreet Sabharwal

Hi Thomas >> Is there any work in progress on updating the TFM CMSIS Pack to use the updated TFM sources? Yes, we are aiming to release an updated TF-M pack this month with updated TF-M source code. Regards Darshpreet -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 09 January 2019 15:45 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [Tf-m] ARM.TFM CMSIS pack questions Thanks Antonio, I now think I know what the dependency on CMSIS 5.2.0 is. In tfm_id_mngr_dummy.c, which seems to have been removed recently, there are a couple of calls into private functions of the RTX5 library which are declared "static" in the later versions of CMSIS, and this causes link errors when using later versions of CMSIS. Is there any work in progress on updating the TFM CMSIS Pack to use the updated TFM sources? Thanks, Thomas Den 2019-01-08 kl. 15:20, skrev Antonio De Angelis via TF-M: > Hi Thomas, > > After this patch has been merged in November: > http://git.trustedfirmware.org/trusted-firmware-m.git/commit/?id=2b328 > e94bcae2d762169bd30f3d7ebc0c2880b5b > > We don't have any reliance on CMSIS 5.2.0 internals anymore and we use only the public CMSIS interface in the Non-Secure API. As a result, I don't see any reason now that stops us from using newer versions of CMSIS. I have actually tried to build TF-M and run regression using CMSIS 5.3.0 and it works as expected. Can you try to see if you're able to build with CMSIS 5.5.0 as well? In case you see issues, I should be able to have a look to understand them better and come with a solution. > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Thomas Törnblom via TF-M > Sent: 07 January 2019 11:48 > To: tf-m(a)lists.trustedfirmware.org > Subject: [Tf-m] ARM.TFM CMSIS pack questions > > Greetings! > > I am working on adding support for IAR Embedded Workbench for ARM > (EWARM) to the ARM.TFM.1.1.0 CMSIS Pack and in the ReadMe.txt file in the pack there is a list of limitations, of which I would like an explanation for the following: > --- > 2. The Non-Secure API supports CMSIS 5.2.0 version only. > --- > > What specifically requires version 5.2.0 that would not work with a later version? > > The problem is that I've run across some issues that needs fixing in the ARM.CMSIS pack as well, so I've fixed these in the upcoming 5.5.0 version and would like to know what the issues are using this version with TFM? > > Thanks, > /Thomas > -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 2 months

1
0
0 0

Re: [Tf-m] ARM.TFM CMSIS pack questions

by Thomas Törnblom

Thanks Antonio, I now think I know what the dependency on CMSIS 5.2.0 is. In tfm_id_mngr_dummy.c, which seems to have been removed recently, there are a couple of calls into private functions of the RTX5 library which are declared "static" in the later versions of CMSIS, and this causes link errors when using later versions of CMSIS. Is there any work in progress on updating the TFM CMSIS Pack to use the updated TFM sources? Thanks, Thomas Den 2019-01-08 kl. 15:20, skrev Antonio De Angelis via TF-M: > Hi Thomas, > > After this patch has been merged in November: > http://git.trustedfirmware.org/trusted-firmware-m.git/commit/?id=2b328e94bc… > > We don't have any reliance on CMSIS 5.2.0 internals anymore and we use only the public CMSIS interface in the Non-Secure API. As a result, I don't see any reason now that stops us from using newer versions of CMSIS. I have actually tried to build TF-M and run regression using CMSIS 5.3.0 and it works as expected. Can you try to see if you're able to build with CMSIS 5.5.0 as well? In case you see issues, I should be able to have a look to understand them better and come with a solution. > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M > Sent: 07 January 2019 11:48 > To: tf-m(a)lists.trustedfirmware.org > Subject: [Tf-m] ARM.TFM CMSIS pack questions > > Greetings! > > I am working on adding support for IAR Embedded Workbench for ARM > (EWARM) to the ARM.TFM.1.1.0 CMSIS Pack and in the ReadMe.txt file in the pack there is a list of limitations, of which I would like an explanation for the following: > --- > 2. The Non-Secure API supports CMSIS 5.2.0 version only. > --- > > What specifically requires version 5.2.0 that would not work with a later version? > > The problem is that I've run across some issues that needs fixing in the ARM.CMSIS pack as well, so I've fixed these in the upcoming 5.5.0 version and would like to know what the issues are using this version with TFM? > > Thanks, > /Thomas > -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

7 years, 2 months

1
0
0 0

Re: [Tf-m] ARM.TFM CMSIS pack questions

by Antonio De Angelis

Hi Thomas, After this patch has been merged in November: http://git.trustedfirmware.org/trusted-firmware-m.git/commit/?id=2b328e94bc… We don't have any reliance on CMSIS 5.2.0 internals anymore and we use only the public CMSIS interface in the Non-Secure API. As a result, I don't see any reason now that stops us from using newer versions of CMSIS. I have actually tried to build TF-M and run regression using CMSIS 5.3.0 and it works as expected. Can you try to see if you're able to build with CMSIS 5.5.0 as well? In case you see issues, I should be able to have a look to understand them better and come with a solution. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 07 January 2019 11:48 To: tf-m(a)lists.trustedfirmware.org Subject: [Tf-m] ARM.TFM CMSIS pack questions Greetings! I am working on adding support for IAR Embedded Workbench for ARM (EWARM) to the ARM.TFM.1.1.0 CMSIS Pack and in the ReadMe.txt file in the pack there is a list of limitations, of which I would like an explanation for the following: --- 2. The Non-Secure API supports CMSIS 5.2.0 version only. --- What specifically requires version 5.2.0 that would not work with a later version? The problem is that I've run across some issues that needs fixing in the ARM.CMSIS pack as well, so I've fixed these in the upcoming 5.5.0 version and would like to know what the issues are using this version with TFM? Thanks, /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 2 months

1
0
0 0

ARM.TFM CMSIS pack questions

by Thomas Törnblom

Greetings! I am working on adding support for IAR Embedded Workbench for ARM (EWARM) to the ARM.TFM.1.1.0 CMSIS Pack and in the ReadMe.txt file in the pack there is a list of limitations, of which I would like an explanation for the following: --- 2. The Non-Secure API supports CMSIS 5.2.0 version only. --- What specifically requires version 5.2.0 that would not work with a later version? The problem is that I've run across some issues that needs fixing in the ARM.CMSIS pack as well, so I've fixed these in the upcoming 5.5.0 version and would like to know what the issues are using this version with TFM? Thanks, /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

7 years, 2 months

1
0
0 0

TF-m Musca_A Tickets

by murat＠za-ya.co

Hi all, We are trying to run the TF-m on Musca-A board, but we have found some blocker issues * T-165: Musca A wrong offset for Secure/NonSecure ROM Alias <https://developer.trustedfirmware.org/T165> * T-166: Is it missing to initialise the MPC for Non-Secure QSPI address range? <https://developer.trustedfirmware.org/T166> Once we apply the fixes mentioned in the tickets, TF-m works well on Musca Board so, could you please review tickets, we might create PRs for them. Best Regards. Murat Cakmak

7 years, 2 months

1
0
0 0

IPC design and implementation ready for review

by Ken Liu (Arm Technology China)

Hi folks, The IPC design and implementation for PSA API are now pushed for review. This design showcases: - PSA Firmware Framework compatible IPC implementation You can find the design document here: https://developer.trustedfirmware.org/w/tf_m/design/ipc_design/ And issue tracker with gerrit items commented: https://developer.trustedfirmware.org/T113 Discussion and review comments are welcome. We will continue work on IPC topics for missing pieces. Thanks. -Ken

7 years, 2 months

1
0
0 0

Re: [Tf-m] Uniform secure service signature proposal

by Antonio De Angelis

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

7 years, 3 months

1
0
0 0

IRQ handling by Secure Partitions proposal

by Miklos Balint

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)

7 years, 3 months

1
0
0 0

Uniform secure service signature proposal

by Miklos Balint

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.

7 years, 3 months

1
2
0 0

Re: [Tf-m] Uniform secure service signature proposal

by Miklos Balint

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

7 years, 3 months

1
0
0 0

Re: [Tf-m] Uniform secure service signature proposal

by Miklos Balint

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.

7 years, 3 months

1
0
0 0

Re: [Tf-m] Uniform secure service signature proposal

by Antonio De Angelis

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

7 years, 3 months

1
0
0 0

Attestation implementation proposal

by Laurence Lundblade

Hi folks, I’m a contractor doing an implementation of attestation based on EAT <https://tools.ietf.org/html/draft-mandyam-eat-01> for TF-M. Tamas asked that I post the proposed architecture here for discussion. It is in this ticket: https://developer.trustedfirmware.org/T152 LL

7 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M