- TF-M - lists.trustedfirmware.org

Invitation: TF-M Tech Forum (US TZ) @ Every 4 weeks from 16:00 to 17:00 on Thursday from Thu 14 May to Sat 1 Aug (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum (US TZ) 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 4 weeks from 16:00 to 17:00 on Thursday from Thu 14 May to Sat 1 Aug 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=MW5vZW9lcmloY2l2aWhpa… 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, 9 months

1
0
0 0

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

by Sandrine Bailleux

Hi all, I've received very little feedback on version 2 of the proposal, which hints that we are reaching an agreement. Thus, I plan to finalize the proposal this week. This can then become part of our development flow for all trustedfirmware.org projects. Thanks again for all the inputs! Regards, Sandrine Bailleux

5 years, 9 months

1
0
0 0

IAR related changes needing review and merge

by Thomas Törnblom

I have submitted a few patches to allow building with IAR after recent changes. https://review.trustedfirmware.org/c/trusted-firmware-m/+/3982 https://review.trustedfirmware.org/c/trusted-firmware-m/+/3997 https://review.trustedfirmware.org/c/trusted-firmware-m/+/4022 I would be happy for review and merge. 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>

5 years, 9 months

1
0
0 0

Re: [TF-M] LPC55S69 support merged into master

by Thomas Törnblom

Hi Kevin, Are there any plans to add ARMCLANG as a build environment for this? If so, then I can add an IAR port as well. Going from ARMCLANG to IAR is much easier than to go from GNUARM to IAR. I have access to one of these boards so will be able to run regression tests as well. Cheers, Thomas Den 2020-04-29 kl. 15:03, skrev Kevin Townsend via TF-M: > Hi, > > Just a quick note that support for the LPC55S69 was just merged in, > allowing you to use the relatively easy to source LPCXpresso55S69-EVK > dev board: > https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… > > Some notes on how to use this board with TF-M are visible here, > including how to update the board to use the Segger J-Link firmware > image: > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… > > Samples scripts for building and flashing (which assume the J-Link > debug firmware is present) are available here: > > - > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… > - > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… > > If you find any issues with the board support, you can comment on the > LPC55S69 task here: https://developer.trustedfirmware.org/T706 > > Best regards, > Kevin Townsend > -- *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, 9 months

2
1
0 0

Improve library model secure function entry points

by David Hu

Hi all, I uploaded a patch (https://review.trustedfirmware.org/c/trusted-firmware-m/+/4009) to simplify/improve the entry points of secure functions in Library model. In current Library model implementation, each secure function includes the same inline entry point tfm_core_partition_request(). Actually, only the NS client check is required to be inline. The duplicated entry points cost much code size. Thus this patch extracts NS client check and make it as a simple inline function tfm_core_is_ns_client(). tfm_core_partition_request() becomes a normal function called by each secure function. Some quantitative results of code size optimization (about 3KB) are shown below: Profile Small (ConfigDefaultProfileS) is based on https://review.trustedfirmware.org/q/topic:%22symmetric-attest%22+(status:o… ConfigDefault + Armclang 6.10 + Release + AN521 Code RO-data RW-data ZI-data Current impl 129778 8994 272 50108 Improved 126294 8994 272 50108 ConfigDefaultProfileS + Armclang 6.10 + Release + AN521 Code RO-data RW-data ZI-data Current impl 55886 3274 200 31664 Improved 52930 3274 200 31664 Best regards, Hu Ziji

5 years, 9 months

1
0
0 0

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

by Vinay Kumar Kotegowder

Hi Raymond, There are some changes required for PSoC64 target with the recent changes from Jamie on persistent key support for test_c050 (api-tests/dev_apis/crypto/test_c050). I will be pushing changes to GitHub today. You could try them and let us know if you are still facing problem. Regards, Vinay ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, April 27, 2020 8:03 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; Jamie Fox <Jamie.Fox(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] PSA Crypto failure with addition of persistent keys 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. 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, 9 months

2
2
0 0

Re: [TF-M] TF-M Technical Forum call - April 30

by Anton Komlev

Hello, The agenda of the call is: 1. introduction to a mechanism efficiency improvement by reducing 'psa_connect'/'psa_close'calls. 2. Mailing List topics discussion (optional) 3. AOB Best regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 28 April 2020 07:17 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - April 30 Hi Anton, I would like to give a brief introduction for a mechanism which would improve the coding efficiency and performance for RoT Service API by avoiding 'psa_connect'/'psa_close'. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, April 23, 2020 3:29 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] TF-M Technical Forum call - April 30 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, 9 months

1
0
0 0

Re: [TF-M] LPC55S69 support merged into master

by Andrej Butok

Hi Kevin, Thank you very much for your successfully efforts and taking care for the TFM LPC55S69 upstream. Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Wednesday, April 29, 2020 3:04 PM To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] LPC55S69 support merged into master Hi, Just a quick note that support for the LPC55S69 was just merged in, allowing you to use the relatively easy to source LPCXpresso55S69-EVK dev board: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.c…> Some notes on how to use this board with TF-M are visible here, including how to update the board to use the Segger J-Link firmware image: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> Samples scripts for building and flashing (which assume the J-Link debug firmware is present) are available here: - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> If you find any issues with the board support, you can comment on the LPC55S69 task here: https://developer.trustedfirmware.org/T706<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…> Best regards, Kevin Townsend

5 years, 9 months

1
0
0 0

LPC55S69 support merged into master

by Kevin Townsend

Hi, Just a quick note that support for the LPC55S69 was just merged in, allowing you to use the relatively easy to source LPCXpresso55S69-EVK dev board: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Some notes on how to use this board with TF-M are visible here, including how to update the board to use the Segger J-Link firmware image: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… Samples scripts for building and flashing (which assume the J-Link debug firmware is present) are available here: - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… If you find any issues with the board support, you can comment on the LPC55S69 task here: https://developer.trustedfirmware.org/T706 Best regards, Kevin Townsend

5 years, 9 months

1
0
0 0

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by Ken Liu

Hi Reinhard, About the CMSIS documentation change, could you share us the difference to be updated? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, April 28, 2020 10:54 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION Hi Ken, Thanks for feedback. TFM_NS_CLIENT_IDENTIFICATION is based on https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The CMSIS documentation is misleading and I can see why you think it is easy to manage secure storage using the same interface. RTOS Thread Context Management<https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…> relates as the name indicates to specific threads. It is used to manage the secure stack space for NS->S function calls that are directly initiated by a thread. When the same mechanism is used to protect permanent storage, it implies that this storage is always accessed by the same thread. However user applications may create/destroy threads (run a different combination of threads) which would break this protection already during run time. Moreover when you update your firmware image on the secure side, the thread IDs (module ID) are likely to change, hence a new firmware version might be unable to retrieve information that was stored by a previous version. Long story short: * I cannot see that TFM_NS_CLIENT_IDENTIFICATION gives us a solution that works in partice. * I will request to fix the CMSIS documentation for "Thread Context Management"; make it clear that is about thread execution. In a nutshell: we should consider to remove TFM_NS_CLIENT_IDENTIFICATION as I cannot see that it works. Reinhard

5 years, 9 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M