- TF-M - lists.trustedfirmware.org

by Reinhard Keil

Is there somewhere a high-level documentation for the platform interfaces that are here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/includ… What are the dependencies of the services to the platform files? For example, when is nv_counters used? Reinhard

5 years, 10 months

1
0
0 0

Re: [TF-M] PSA Crypto failure with addition of persistent keys

by David Hu

Hi Raymond, Sorry for the trouble. Sorry that I cannot find a Crypto test case with index 250. Could you please share more details and error logs of this test case? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: Monday, April 27, 2020 10:26 AM To: tf-m(a)lists.trustedfirmware.org; Jamie Fox <Jamie.Fox(a)arm.com> Subject: [TF-M] PSA Crypto failure with addition of persistent keys Hi Jamie, With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack. Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. 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.

5 years, 10 months

1
0
0 0

PSA Crypto failure with addition of persistent keys

by Raymond Ngun

Hi Jamie, With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack. Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 10 months

1
0
0 0

Re: [TF-M] [RFC] The veneer usage under library model

by Ken Liu

Looks no more feedbacks. We will start creating it and call for review when finished. Issue created for collecting comments: https://developer.trustedfirmware.org/T720 Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, April 9, 2020 4:32 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] The veneer usage under library model (Ken Liu) Hi Reinhard, Thanks for your feedback, and let's see if others would give more comments. Will broadcast the implementation after it is created. Before that we need to know if some users (especially those developing secure partitions under library model) got comments on this. Also, I think this update could help the first point in your list. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 9, 2020 2:57 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [RFC] The veneer usage under library model (Ken Liu) Ken, This is the answer to "What do you think about this update?" When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine. I made some suggestions here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html I would be happy to review your implementation in case that you have doubts. Best regards Reinhard

5 years, 11 months

1
0
0 0

Request for comments on TF-M Profile Small design updates

by David Hu

Hi all, Hope you are doing well. May I ask for your review on the latest Profile Small design? The design has been updated with following major changes: * The default AES mode is changed to CCM mode from CBC mode, to achieve more secured connection. * More details on the use case of Profile Small Please review the document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Please feel free to comment. Thank you! The patch set is updated as well, following the latest design. Please check it on https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o…. Compared with previous versions, CCM is supported and some configurations are selected to optimize the Crypto memory footprint. Best regards, Hu Ziji

5 years, 11 months

1
0
0 0

TF-M Technical Forum call - April 30

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, April 30 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 11 months

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Tamas Ban

Bug fix merged: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3943 -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:26 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Bug being tracked at https://developer.trustedfirmware.org/T716, aiming to get the fix pushed in a few minutes Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 13:06 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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. -- 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. -- 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 11 months

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Raef Coles

Bug being tracked at https://developer.trustedfirmware.org/T716, aiming to get the fix pushed in a few minutes Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 13:06 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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. -- 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. -- 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.

5 years, 11 months

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Tamas Ban

Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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. -- 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.

5 years, 11 months

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Raef Coles

Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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.

5 years, 11 months

1
0
0 0

Build issues with MCUBoot merge

by Thomas Törnblom

I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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>

5 years, 11 months

1
0
0 0

Re: [TF-M] Will TFM crypto service suppot national encryption algorithm in the future?

by Shebu Varghese Kuriakose

Hi Matt, TF-M plans to continue using Mbedcrypto in the crypto service. Mbed Crypto implements the PSA Crypto APIs and is also now part of trustedfirmware.org community project alongside TF-M. However, it is possible with some effort for a platform using TF-M to use another crypto library in the TF-M crypto service. Of course the library will need to support PSA Crypto APIs to be PSA compliant. There is support for ARIA, Camellia in Mbed TLS. There has already been a PR for SM4 support sometime back - https://github.com/ARMmbed/mbedtls/pull/1165. SM2/SM3 algorithm support can be contributed to MbedTLS project (Mbed Crypto is now merged to Mbed TLS project). The maintainers will have to review and integrate the contribution as their bandwidth permits while finding time to review several contributions that the project is receiving. I am adding psa-crypto mailing list which is used for Mbedcrypto/PSA Crypto discussions. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Matt via TF-M Sent: Thursday, April 16, 2020 8:24 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Will TFM crypto service suppot national encryption algorithm in the future? Hi All TFM experts, TFM crypto service is based on mbedcrypto and there is no national encryption algorithm support in current mbedcrypto implementation. The Chinese market has a strong demand for national encryption algorithms, such as SM2/SM3/SM4, will TFM crypto service change to other crypto implementation to support the national encryption algorithm in the future? Thanks, -Matt

5 years, 11 months

2
1
0 0

Will TFM crypto service suppot national encryption algorithm in the future?

by Matt

Hi All TFM experts, TFM crypto service is based on mbedcrypto and there is no national encryption algorithm support in current mbedcrypto implementation. The Chinese market has a strong demand for national encryption algorithms, such as SM2/SM3/SM4, will TFM crypto service change to other crypto implementation to support the national encryption algorithm in the future? Thanks, -Matt

5 years, 11 months

1
0
0 0

Re: [TF-M] [TF-A] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi all, Thanks to all who have commented on this proposal so far. I've edited the original document to try and incorporate all feedback gathered so far (through the TSC meeting, this email thread and the TF-A tech call). Please have another look and flag anything I might have missed: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… The major changes are: == Removed concept of self-review == This is proving too controversial, several people do not want to allow self-review. Roles of maintainer and code owner are still cumulative but cannot be both exercised for the same patch. The exact method of dealing with review bottleneck is still to be decided. In addition to the current proposal of increasing the maintainers pool, the most popular alternatives mentioned so far are: - Set a minimum wait time for feedback before a patch can be merged without any further delay. - Mandate distinct reviewers for a patch. == Enhanced the section "Patch contribution Guidelines" == Mentioned that patches should be small, on-topic, with comprehensive commit messages. == Added a note about how to deal with disagreement == If reviewers cannot find a common ground, the proposal is to call out a 3rd-party maintainer. == Removed "out-of-date" platform state == Squashed it into "limited support" to reduce the number of states. == Removed "orphan" state from platform support life cycle == This concept is orthogonal to the level of functionality. Added a note in the "Code Owner" section instead. == Per-project guidelines as a complementary document == Added a list of things that it would typically cover. == Added requirement on fully supported platforms to document the features they support == == Added todo mentioning that the proposal might cover branching strategies in the future == The full diff may be seen here: https://developer.trustedfirmware.org/phriction/diff/73/?l=4&r=5 This proposal is still open for discussion at this stage and further feedback is most welcome! Regards, Sandrine

5 years, 11 months

1
0
0 0

Design of symmetric key algorithms based Initial Attestation in TF-M

by David Hu

Hi all, Hope you all well! Profile Small (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598) includes symmetric key algorithm based Initial Attestation, as its Initial Attestation feature. I propose a design of symmetric key algorithm based Initial Attestation in TF-M, to complete the Profile Small feature list. Could you please take a look the design document at https://review.trustedfirmware.org/c/trusted-firmware-m/+/3898/? Any feedback is welcome! I also upload a PoC of symmetric key algorithm based Initial Attestation in TF-M. Please check the patch set at https://review.trustedfirmware.org/q/topic:%22symmetric-attest%22+(status:o…. Best regards, Hu Ziji

5 years, 11 months

1
0
0 0

TF-M Technical Forum call - April 16

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, April 16 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 11 months

1
0
0 0

Invitation: TF-M Tech Forum @ Every 2 weeks from 07:00 to 08:00 on Thursday 2 times (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h When: Every 2 weeks from 07:00 to 08:00 on Thursday 2 times United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NmJrNmtzbHVyYThiczFkY… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 11 months

1
0
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Shreve, Erik

I see the discussion of today's tech forum agenda has begun ahead of time. :) Individual public key operations can take ms even when accelerated with HW. Further, the HW accelerators operate as math coprocessors with a series of math operations stitched together by SW. No doubt existing models in TF-M have the benefit of simplicity for the secure code analysis. However, their simplicity complicates the scheduling of the non-trusted code. The qualifier in this statement "No impact to time deterministic execution on the NS side unless two threads call secure services" is the issue. I believe we need a middle ground to drive additional adoption. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Thursday, April 02, 2020 9:47 AM To: Reinhard Keil; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal I used crypto accelerator as a hypothetical example. In a real world use case we are faced with, the process kicked off by the secure service may take a long time (ie several ms). It is not acceptable to be parked in wfe during that time. Alan From: Reinhard Keil [mailto:Reinhard.Keil@arm.com] Sent: Thursday, April 2, 2020 6:52 AM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal Alan, "I was afraid that this was the proposal. No lower priority NS threads can run while waiting for the secure interrupt. Only higher priority threads that are initiated by a NS interrupt can run." You are correct, scheduling of lower priority NS threads would be not possible. This is definitely a shortcoming of the solution. May I ask: how long does a hardware crypto operation take? What time could be used for low priority NS thread execution? Reinhard

5 years, 11 months

3
4
0 0

Re: [TF-M] Using tfm_plat_get_huk_derived_key(), TFM key-storage?

by Jamie Fox

Hi Andrej, Key derivation should be deterministic - given the same input parameters, tfm_plat_get_huk_derived_key() should always derive the same key. Each platform needs to implement tfm_plat_get_huk_derived_key() to use a key derivation function (KDF) to derive keys from the hardware unique key (HUK) that is kept in some one time programmable (OTP) memory on the chip. Depending on the platform, the key derivation might be done with a crypto accelerator, or it might be done with a software implementation of a KDF if no accelerator is available. You can use the Musca-B1 implementation as an example (https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…), which uses CryptoCell-312 to derive keys from the HUK. Other Arm platforms only have dummy implementations of this function. In general, users of this API will keep their derived keys in volatile memory and redo the key derivation on each boot, as the cost of key derivation is low. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 09 April 2020 11:49 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Using tfm_plat_get_huk_derived_key(), TFM key-storage? Hello, Could you clarify: 1) Must the tfm_plat_get_huk_derived_key() function to return the same key per each call (as it's done now), or it may return randomized key (per each call) derived from HUK? 2) If tfm_plat_get_huk_derived_key() may return a different key per call, the generated key must be stored in persistent storage. Is this key persistent storage already implemented (using the default parameters) for example in ITS, or the key-storage must be implemented additionally? It looks like the current TFM key storage is placed in RAM, or I have missed something? Thank you, Andrej Butok

5 years, 11 months

2
1
0 0

Using tfm_plat_get_huk_derived_key(), TFM key-storage?

by Andrej Butok

Hello, Could you clarify: 1) Must the tfm_plat_get_huk_derived_key() function to return the same key per each call (as it's done now), or it may return randomized key (per each call) derived from HUK? 2) If tfm_plat_get_huk_derived_key() may return a different key per call, the generated key must be stored in persistent storage. Is this key persistent storage already implemented (using the default parameters) for example in ITS, or the key-storage must be implemented additionally? It looks like the current TFM key storage is placed in RAM, or I have missed something? Thank you, Andrej Butok

5 years, 11 months

1
0
0 0

Re: [TF-M] [RFC] The veneer usage under library model (Ken Liu)

by Ken Liu

Hi Reinhard, Thanks for your feedback, and let's see if others would give more comments. Will broadcast the implementation after it is created. Before that we need to know if some users (especially those developing secure partitions under library model) got comments on this. Also, I think this update could help the first point in your list. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 9, 2020 2:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] The veneer usage under library model (Ken Liu) Ken, This is the answer to "What do you think about this update?" When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine. I made some suggestions here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html I would be happy to review your implementation in case that you have doubts. Best regards Reinhard

5 years, 11 months

1
0
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Ken Liu

Hi Erik, Could you share us more design details such as the slides you presented in Tech Forum, the progress and so on? We want to see more details (the more the better I think) and then we could discuss more precisely. Also, if this design has been prototyped, try to collect some data would be much helpful. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 9, 2020 2:51 PM To: Shreve, Erik <e-shreve(a)ti.com>; DeMars, Alan <ademars(a)ti.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal Erik, I believe we should measure timing behaviour and document it first before come to conclusions. Personally I have not reviewed the IPC mode. I was just reviewing the SFN (aka Library mode) and measured the current implementation (actually it was a RC3+patches version). My result and assessment is here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html - it has as expected for v1 "room for improvement". Did you do similar tests with the IPC model already? Do you have timing measurements of the HW crypto accelerator operations? From the STM32L5 data sheet we are getting 410 cycles as the maximum time of an AES 256-byte key decrypt operation (most operations seems to take less than 100 cycles). The fact that crypto is time consuming is not new for system designers that use a single core processor. As said the solution in today's applications is: * Crypto is in "Normal" priority * Time critical execution is "High" priority - this threads can preempt execution of "Normal" priority threads. Have a happy Easter time and stay healty! Reinhard From: Shreve, Erik <e-shreve(a)ti.com<mailto:e-shreve@ti.com>> Sent: Tuesday, April 7, 2020 3:24 PM To: Reinhard Keil <Reinhard.Keil(a)arm.com<mailto:Reinhard.Keil@arm.com>>; DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Multi-threaded single-scheduler model proposal Reinhard, I'm happy to engage in discussion over email. Didn't mean to send any other impression. Also, appreciate your feedback on the proposal. Elegance is in the eye of the beholder, but that said I think that the IPC model does have an elegance to it. However, its elegance imposes limitations that complicate the entirety of _some_ systems - leading to less overall elegance in _those_ systems. The IPC model isn't bad or inappropriate, it's a great solution. It just doesn't cover everything (what could?) Further, if a middle ground is needed but there exists no 'elegant' solution then a solution a bit less than elegant may be required. Also, no debate that the IPC model is not much different from when users are running mbedTLS only in a dedicated thread, but that is not how we see crypto used in our ecosystem. There are many industrial and automotive use cases where determinism is required. Further, both of these markets are seeing an uptick in security interest and even regulation pressure. And these markets don't like change. Change implies opening products back up to costly verification and validation activities and risk. I can't share particulars on this email list, but I can say that any system supporting multiple concurrent connections wherein different connections have different priority and at least some of those have deterministic response requirements will have difficulty adopting the IPC model. (Of course there are other ways to solve this such as increased clock rate or duplicated HW accelerators, but these impact die cost and can negatively impact power performance.) Keep in mind that not all connections are TLS connections over the internet where a few milliseconds would be noise. But based on your statement "Maybe there are other solutions that extending the RTOS kernel," I'm wondering if I've not communicated the idea well enough. The RTOS kernels would only be extended by the calling of tz_context APIs during task switching. This is something that is already occurring in the IPC model. (You mention that using the tz_context APIs is "tricky," can you elaborate more on this?) There is then a TF-M _to_ RTOS layer allowing secured code to signal semaphore and mutex usage to the RTOS. The RTOS kernel itself has no changes for this layer. Thus, I see the impact to the RTOS kernels as minimal. And since the RTOS retains the same control over when tasks run, there is minimal (if any) impact to application code. I think one of your concerns is adoption of TF-M and that it may be negatively impacted if difficult integration with each RTOS is required. Yes? If so, I am sharing your concern about adoption, but I think the bigger hindrance is not the RTOS integration but application level integration. After all there are far fewer RTOSes than applications in the world. Likely our different experiences are leading us to different conclusions here despite a shared concern. But providing a few well selected options can maximize adoption for effort. At the end of the Tech Forum meeting someone suggested a model like this could replace (or upgrade) the Library model. Regarding HW run times, the specifics really are in cycle counts if we want to compare them with the cost of task switching. Many ECC (and certainly RSA/DSA/DH) math operations take much longer (millions of cycles) than the time to switch a task. Finally, regarding minimal viable product (MVP), I understand the purpose of an MVP to either be a platform to gain feedback toward a product launch or a minimum product that is useful to early adopters. Either way, it seems that with the release of TF-M 1.0 this has been achieved. So then the next steps are to incorporate feedback and grow the market of the product. Growing the market use of TF-M is what I seek to do with the proposal. Again, appreciate the discussion. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: Reinhard Keil [mailto:Reinhard.Keil@arm.com] Sent: Friday, April 03, 2020 7:26 AM To: Shreve, Erik; DeMars, Alan Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal Erik, Alan, Sorry I had not enough time to participate the whole meeting yesterday and I therefore kicked-off some discussion before. It's really great to see your engagement here. Let me summarize: TF-M should work with many different RTOSes as the various CSPs currently have preferences (Azure=ThreadX, AWS=FreeRTOS, etc.). To make it easy to work with this diverse eco-system we should aim for simplicity of TF-M/RTOS interaction. Also tz_context slows down overall thread switching and is tricky to use. I agree with you that we will need a middle ground. You say: "No impact to time deterministic execution on the NS side unless two threads call secure services" is the issue. However I cannot see today an elegant solution. My question is: what use-cases do you see where two different threads need to call secure services. Is in such use-cases timing a critical factor? Alan raised "In a real world use case we are faced with, the process kicked off by the secure service may take a long time (ie several ms)". This is correct, but makes it really sense to schedule CPU execution. HW accelerator math operations take some ~1usec; thread scheduling is not economic. IMHO: It is not different from today's implementation where i.e. mbedTLS is running in a thread. For time critical applications you would solve that problem with thread priorities where: * Crypto is in "Normal" priority * Time critical execution is "High" priority I believe we should focus first on a minimum viable product and then analyze the real-world problems that come with it. Maybe there are other solutions that extending the RTOS kernel. Have a good weekend. Reinhard From: Shreve, Erik <e-shreve(a)ti.com<mailto:e-shreve@ti.com>> Sent: Thursday, April 2, 2020 4:55 PM To: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>>; Reinhard Keil <Reinhard.Keil(a)arm.com<mailto:Reinhard.Keil@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Multi-threaded single-scheduler model proposal I see the discussion of today's tech forum agenda has begun ahead of time. :) Individual public key operations can take ms even when accelerated with HW. Further, the HW accelerators operate as math coprocessors with a series of math operations stitched together by SW. No doubt existing models in TF-M have the benefit of simplicity for the secure code analysis. However, their simplicity complicates the scheduling of the non-trusted code. The qualifier in this statement "No impact to time deterministic execution on the NS side unless two threads call secure services" is the issue. I believe we need a middle ground to drive additional adoption. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Thursday, April 02, 2020 9:47 AM To: Reinhard Keil; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal I used crypto accelerator as a hypothetical example. In a real world use case we are faced with, the process kicked off by the secure service may take a long time (ie several ms). It is not acceptable to be parked in wfe during that time. Alan From: Reinhard Keil [mailto:Reinhard.Keil@arm.com] Sent: Thursday, April 2, 2020 6:52 AM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal Alan, "I was afraid that this was the proposal. No lower priority NS threads can run while waiting for the secure interrupt. Only higher priority threads that are initiated by a NS interrupt can run." You are correct, scheduling of lower priority NS threads would be not possible. This is definitely a shortcoming of the solution. May I ask: how long does a hardware crypto operation take? What time could be used for low priority NS thread execution? Reinhard

5 years, 11 months

1
0
0 0

[RFC] The veneer usage under library model (Ken Liu)

by Reinhard Keil

Ken, This is the answer to "What do you think about this update?" When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine. I made some suggestions here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html I would be happy to review your implementation in case that you have doubts. Best regards Reinhard

5 years, 11 months

1
0
0 0

[RFC] The veneer usage under library model

by Ken Liu

Hi, There are veneer prototypes in 'tfm_veneers.h', with different function name but the same parameters. These veneers are for the library model. I think these veneers can be combined into one and use a parameter 'type' to dispatch to the actual functions. What do you think about this update? Would this change impact your development much? Please provide your comments. Thanks. /Ken

5 years, 11 months

1
0
0 0

Re: [TF-M] [TF-A] TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org

by Joanna Farley

I realise non TF-A people may not have access to session conference details. These can be found here: https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000330.html From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Tuesday, 7 April 2020 at 18:10 To: tf-a <tf-a(a)lists.trustedfirmware.org> Cc: "tsc(a)lists.trustedfirmware.org" <tsc(a)lists.trustedfirmware.org>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>, "op-tee(a)linaro.org" <op-tee(a)linaro.org> Subject: [TF-A] TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org Hi All, The third TF-A Tech Forum is scheduled for Thu 9th Apr 2020 17:00 - 18:00 (GMT). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. For this special session I have also copied the TF-M, TSC and OPTEE mailing lists as the subject may interest the people subscribed to those lists as there is a cross mailing list discussion currently ongoing. Agenda: * Overview of the Project Maintenance Proposal for tf.org Projects by Sandrine Bailleux * Optional TF-A Mailing List Topic Discussions Thanks Joanna 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. 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.

5 years, 11 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M