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.
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.
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
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
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
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
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.
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.
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.
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>
