- TF-M - lists.trustedfirmware.org

TFM 1.0 integration merged into upcoming Zephyr 2.3

by Kevin Townsend

Hi, Just as a FYI, TF-M 1.0 support was merged into Zephyr RTOS this week, meaning that it will be included by default in Zephyr starting with the upcoming 2.3 release. Zephyr is used on the non-secure side, and TF-M is used on the secure side, with the TF-M build happening as part of the normal Zephyr build process, meaning no knowledge of TF-M internals is required to get started. It's also worth highlighting QEMU integration with Zephyr+TF-M. Using the MPS2 AN521 target, you can run application from the command-line with QEMU, meaning that you can create test applications that use the PSA APIs with no HW required, or perform certain application tests purely in SW. As an example, the following sample was run with a clean install of Zephyr, showing QEMU output and demonstrating how to use the initial attestation, crypo and secure storage services: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/tfm_integr… $ mkdir zephyrtfm && cd zephyrtfm $ west init $ west update $ west build -p -b mps2_an521_nonsecure zephyr/samples/tfm_integration/psa_level_1/ -t run [INF] Starting bootloader [INF] Swap type: none [INF] Swap type: none [INF] Bootloader chainload address offset: 0x80000 [INF] Jumping to the first image slot [Sec Thread] Secure image initializing! TF-M isolation level is: 1 Booting TFM v1.0 *** Booting Zephyr OS build zephyr-v2.2.0-2701-ge5aaf21a73c7 *** [00:00:00.003,000] <inf> app: app_cfg: Creating new config file with UID 0x155cfda7a [00:00:03.518,000] <inf> app: att: System IAT size is: 545 bytes. [00:00:03.518,000] <inf> app: att: Requesting IAT with 64 byte challenge. [00:00:06.925,000] <inf> app: att: IAT data received: 545 bytes. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 D2 84 43 A1 01 26 A0 59 01 D5 AA 3A 00 01 24 FF ..C..&.Y...:..$. 00000010 58 40 00 11 22 33 44 55 66 77 88 99 AA BB CC DD X@.."3DUfw...... 00000020 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000030 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000040 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000050 EE FF 3A 00 01 24 FB 58 20 A0 A1 A2 A3 A4 A5 A6 ..:..$.X ....... 00000060 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 ................ 00000070 B7 B8 B9 BA BB BC BD BE BF 3A 00 01 25 00 58 21 .........:..%.X! 00000080 01 FA 58 75 5F 65 86 27 CE 54 60 F2 9B 75 29 67 ..Xu_e.'.T`..u)g 00000090 13 24 8C AE 7A D9 E2 98 4B 90 28 0E FC BC B5 02 .$..z...K.(..... 000000A0 48 3A 00 01 24 FA 58 20 AA AA AA AA AA AA AA AA H:..$.X ........ 000000B0 BB BB BB BB BB BB BB BB CC CC CC CC CC CC CC CC ................ 000000C0 DD DD DD DD DD DD DD DD 3A 00 01 24 F8 20 3A 00 ........:..$. :. 000000D0 01 24 F9 19 30 00 3A 00 01 24 FD 82 A5 01 63 53 .$..0.:..$....cS 000000E0 50 45 04 65 30 2E 30 2E 30 05 58 20 BF E6 D8 6F PE.e0.0.0.X ...o 000000F0 88 26 F4 FF 97 FB 96 C4 E6 FB C4 99 3E 46 19 FC .&..........>F.. 00000100 56 5D A2 6A DF 34 C3 29 48 9A DC 38 06 66 53 48 V].j.4.)H..8.fSH 00000110 41 32 35 36 02 58 20 B4 74 47 EE 2A 2C A4 73 B2 A256.X .tG.*,.s. 00000120 A5 55 D4 73 6D 7F 8B 42 97 94 C2 36 BC 03 33 04 .U.sm..B...6..3. 00000130 29 C3 E5 9C FF CD C4 A5 01 64 4E 53 50 45 04 65 )........dNSPE.e 00000140 30 2E 30 2E 30 05 58 20 B3 60 CA F5 C9 8C 6B 94 0.0.0.X .`....k. 00000150 2A 48 82 FA 9D 48 23 EF B1 66 A9 EF 6A 6E 4A A3 *H...H#..f..jnJ. 00000160 7C 19 19 ED 1F CC C0 49 06 66 53 48 41 32 35 36 |......I.fSHA256 00000170 02 58 20 07 16 EE 98 EA 6A CC 0F 7A 9A 21 46 E6 .X .....j..z.!F. 00000180 CD 26 B4 0B 3D 4B 35 B4 9C B1 89 57 56 12 66 AB .&..=K5....WV.f. 00000190 72 BD 47 3A 00 01 25 01 77 77 77 77 2E 74 72 75 r.G:..%.wwww.tru 000001A0 73 74 65 64 66 69 72 6D 77 61 72 65 2E 6F 72 67 stedfirmware.org 000001B0 3A 00 01 24 F7 71 50 53 41 5F 49 4F 54 5F 50 52 :..$.qPSA_IOT_PR 000001C0 4F 46 49 4C 45 5F 31 3A 00 01 24 FC 72 30 36 30 OFILE_1:..$.r060 000001D0 34 35 36 35 32 37 32 38 32 39 31 30 30 31 30 58 456527282910010X 000001E0 40 51 33 D9 87 96 A9 91 55 18 9E BF 14 7A E1 76 @Q3.....U....z.v 000001F0 F5 0F A6 3C 7B F2 3A 1B 59 24 5B 2E 67 A8 F8 AB ...<{.:.Y$[.g... 00000200 12 A3 AC 9C E8 44 95 13 60 82 E9 49 43 7B 4E C5 .....D..`..IC{N. 00000210 2C 0D E5 EC BA 72 C5 35 2C F7 C9 1C B7 26 93 80 ,....r.5,....&.. 00000220 12 . [00:00:06.982,000] <inf> app: Generating 256 bytes of random data. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 0C 90 D8 0C FA 0F 97 00 29 B2 AE 5C 90 48 3D 39 ........)..\.H=9 00000010 00 14 6C A3 84 E2 C0 C9 82 F5 8B A6 E9 38 66 16 ..l..........8f. 00000020 EA B7 E7 78 91 0D 6D 87 5B B8 04 0B 8B E0 74 23 ...x..m.[.....t# 00000030 7D 11 E2 17 32 34 1A 01 71 24 29 D5 7C 05 B1 11 }...24..q$).|... 00000040 A0 97 20 82 03 FF D6 76 9D 6F D5 52 45 C9 E1 17 .. ....v.o.RE... 00000050 69 DF 18 B6 8E 0C AA 3B 74 B4 EF 97 D9 0E 82 25 i......;t......% 00000060 E1 97 0E 6E 4F 0F DE B9 20 60 34 A4 EA 0D 9A B3 ...nO... `4..... 00000070 3F C4 9A CF F3 5E F2 2C 78 96 6F 0E DD E3 E6 CB ?....^.,x.o..... 00000080 DC 19 26 A3 E8 8E 07 0E 1E 5B DB 59 B0 05 41 E2 ..&......[.Y..A. 00000090 A4 ED 90 35 8B AB 1C B8 00 7E BB 2D 22 FE 7A EA ...5.....~.-".z. 000000A0 CF A0 BB DF 4F 2B 32 55 C9 07 0D 3D CE B8 43 78 ....O+2U...=..Cx 000000B0 63 33 6C 79 CA 43 3A 4F 0B 93 33 2B B1 D2 B0 A7 c3ly.C:O..3+.... 000000C0 44 A0 E9 E8 BF FB FD 89 2A 44 7A 60 2D 9B 0F 9E D.......*Dz`-... 000000D0 0D B1 0E 9D 5C 60 5D E6 92 78 36 79 68 37 24 C5 ....\`]..x6yh7$. 000000E0 57 7F 2E DF 53 D2 7B 3F EE 56 9B 9E BB 39 2C B6 W...S.{?.V...9,. 000000F0 AA FF B5 3B 59 4E 40 1D E0 34 50 05 D0 E0 95 12 ...;YN@..4P..... [00:00:07.004,000] <inf> app: Calculating SHA-256 hash of value. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 E3 B0 C4 42 98 FC 1C 14 9A FB F4 C8 99 6F B9 24 00000010 27 AE 41 E4 64 9B 93 4C A4 95 99 1B 78 52 B8 55 A big thanks to Karl, who was involved in getting this integration work going during his time as an assignee to the LITE team at Linaro, and to other members of the Zephyr community who got this over the finish line at the last minute, as well as to Mate for some last second feedback and debugging with TF-M in IPC mode using Zephyr. We hope this will make TF-M, and all the hard work that has gone into it, far more accessible to a wider range of people, with HW no longer being an immediate limitation to trying it out. Best regards, Kevin Townsend, Linaro

5 years, 10 months

1
0
0 0

Remove 'INDIVIDUAL_SW_COMPONENTS' support from attestation

by Tamas Ban

Hi, I let you notify that 'INDIVIDUAL_SW_COMPONENTS' support is planned to be removed from attestation service and bootloader. What is this? * Boootloader and SPE can exchange data through shared memory. This is needed to provide the boot status info to attestation service. The boot status info is included in the SW_COMPONENT claim in the attestation token. * Until now two types of data encoding was supported during this data sharing: * All boot status data item is passed as a single TLV entry: -DATTEST_BOOT_INTERFACE=INDIVIDUAL_CLAIMS * Boot status is already encoded to CBOR format at build time. Bootloader only updates a few field in it, and pass the CBOR object to SPE. Then attestation service just include this already CBOR formatted object to the token, without the need to applying further encoding. -DATTEST_BOOT_INTERFACE=CBOR_ENCODED_CLAIMS The 'INDIVIDUAL_CLAIMS' format is marked as deprecated feature for a while in the code base. Now the plan is to remove it and rely fully on the 'CBOR_ENCODED_CLAIMS' format. The build system support for this is present in TF-M for a long, and recently it was upstream to original MCUBoot 'imgtool' script as well. Next MCUBoot release (v1.6) will contain it. If you has any objection, because your project is using the 'INDIVIDUAL_CLAIMS' format then please let us know! BR, Tamas

5 years, 10 months

1
0
0 0

Request for final review of Profile Small design document

by David Hu

Hi all, Profile Small design document has been reviewed for a long time. Thanks a lot for all your comments and suggestions. I'd like to request a final round review. If no further critical comment, the Profile Small design document will be merged next Wednesday. If you have interest in reading the document again, please access https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Best regards, Hu Ziji

5 years, 10 months

1
0
0 0

TF-M Technical Forum call - May 14

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, May 14 at 15:00-16:00 UTC. Please reply on this email with your proposals for agenda topics. To avoid confusion here are some local times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=… Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 14 May 2020, 08:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 14 May 2020, 10:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 14 May 2020, 16:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 14 May 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Best regards, Anton Komlev

5 years, 10 months

1
0
0 0

Invitation: TF-M tech Forum (Asia TZ) @ Every 4 weeks from 07:00 to 08:00 on Thursday from Thu 28 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 (Asia 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 07:00 to 08:00 on Thursday from Thu 28 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=MjJva2xwOGVxaG12bHVha… 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, 10 months

1
0
0 0

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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 months

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by Sherry Zhang

Hi Thomas, OK, the problem is caused by that the names of region related symbols that IRA compiler generate are different with those of ARMCLANG. The work around below do can solve the problem. BTW the work around seems not to be a general one. I think another way to solve the problem is adding a macro like SYMBOL_NAME_BASE(region) which is a wrapper of the REGION_NAME on different compilers. Regards, Sherry Zhang From: Thomas Törnblom <thomas.tornblom(a)iar.com> Sent: Tuesday, April 28, 2020 6:28 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; TF-M <tf-m-bounces(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] REGION_DECLARE macros Hi Sherry, Yes, I noticed that this change had been integrated and that this symbol was being used. I ran into a lot of these during the IAR port and as I said they don't work with the IAR linker. I work around this in CommonConfig.cmake by this define: --- embedded_set_target_compile_flags(TARGET ${tgt} LANGUAGE C FLAGS ${COMMON_COMPILE_FLAGS} "-DImage$$= " "-DLoad$$LR$$= " "-D$$ZI$$Base=$$Base" "-D$$ZI$$Limit=$$Limit" "-D$$RO$$Base=$$Base" "-D$$RO$$Limit=$$Limit" "-D$$RW$$Base=$$Base" "-D$$RW$$Limit=$$Limit" "-D_DATA$$RW$$Base=_DATA$$Base" "-D_DATA$$RW$$Limit=_DATA$$Limit" "-D_DATA$$ZI$$Base=_DATA$$Base" "-D_DATA$$ZI$$Limit=_DATA$$Limit" "-D_STACK$$ZI$$Base=_STACK$$Base" "-D_STACK$$ZI$$Limit=_STACK$$Limit" --- i.e. I replace $$ZI$$Base with $$Base, Image$$ and Load$$LR are removed entirely, and so on. To make this work I need to split the symbol up into its components, which is done with the REGION macros. So the symbol "Image$$ARM_LIB_STACK_MSP$$ZI$$Base" turns into "ARM_LIB_STACK_MSP$$Base", which is what we use for IAR. For ARMCLANG and GNUARM the macros generate the original symbol. Cheers, Thomas Den 2020-04-28 kl. 12:03, skrev Sherry Zhang: Hi Thomas, The diff below is caused by this patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/3942 . REGION_NAME is used to pasting the input parameters into a string. So there should be no difference between Image$$ARM_LIB_STACK_MSP$$ZI$$Base and REGION_NAME(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base) basing on the current implementation of REGION_NAME in file platform/include/region.h So, is there a specific REGION_NAME macro implementation for IAR compiler? Or the automatically generated region related symbols are with different names in IAR compiler? Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Tuesday, April 28, 2020 4:58 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] REGION_DECLARE macros I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software. Trying another type: /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); Den 2020-04-28 kl. 10:51, skrev Thomas Tï¿½rnblom via TF-M: With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains. Example diff: --- ï¿½ï¿½ï¿½ï¿½ /* Set Main Stack Pointer limit */ -ï¿½ï¿½ï¿½ extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; -ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); +ï¿½ï¿½ï¿½ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,ï¿½ $$ZI$$Base); +ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, +ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ $$ZI$$Base)); --- 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> -- 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> -- 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, 10 months

1
0
0 0

Questions on TFM_NS_CLIENT_IDENTIFICATION

by Reinhard Keil

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, 10 months

1
0
0 0

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by David Wang

Hi Reinhard, Add more from user's perspective: The non-secure client id can be used to identify different "clients" from non-secure side. The example from tf-m existing secure service is the storage. Different client id can access different storage space. Therefore, the storage is "isolation" among the clients. The users can create the custom secure service and leverage different client ids (let's say non-secure client id here) to identify different non-secure "callers": * The meaning of identifying different non-secure callers depends on the user case of the secure service. For example, different storage spaces, different access permissions, etc. * In RTOS, different non-secure client ids are managed via TZ_APIs (https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fu…) if they're enabled. * The mapping between non-secure applications and the TZ secure contexts (stand for different client ids in tfm) is managed by NS RTOS kernel. When the ns applications get updated, then the mapping should also be maintained by RTOS kernel. Hope this helps. Refs: [1]: TF-M non-secure ID manager http://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/user_guides… [2]: PR to FreeRTOS which uses different non-secure id for storage service: https://github.com/Linaro/amazon-freertos/pull/1 Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, April 28, 2020 7:00 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION Hi Reinhard, My assumption on the user side: - For application developers, they don't need to care about the identification and just access secure service via API. - For non-secure OS (or, a whole system level including SPE and NSPE) developers or integrators, they can implement a mechanism to help SPM identify the different non-secure threads, then SPM can do more granular client management (access control or other policies). If the don't, then SPM take whole NSPE shares the same non-secure client id and no more granular client management. Still need the real USER to provide more information in case my assumption covers partial scenarios only. Thanks. /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: Tuesday, April 28, 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] Questions on TFM_NS_CLIENT_IDENTIFICATION I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled. However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime. Reinhard

5 years, 10 months

1
0
0 0

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by Ken Liu

Hi Reinhard, My assumption on the user side: - For application developers, they don't need to care about the identification and just access secure service via API. - For non-secure OS (or, a whole system level including SPE and NSPE) developers or integrators, they can implement a mechanism to help SPM identify the different non-secure threads, then SPM can do more granular client management (access control or other policies). If the don't, then SPM take whole NSPE shares the same non-secure client id and no more granular client management. Still need the real USER to provide more information in case my assumption covers partial scenarios only. 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 2:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled. However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime. Reinhard

5 years, 10 months

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by Sherry Zhang

Hi Thomas, The diff below is caused by this patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/3942 . REGION_NAME is used to pasting the input parameters into a string. So there should be no difference between Image$$ARM_LIB_STACK_MSP$$ZI$$Base and REGION_NAME(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base) basing on the current implementation of REGION_NAME in file platform/include/region.h So, is there a specific REGION_NAME macro implementation for IAR compiler? Or the automatically generated region related symbols are with different names in IAR compiler? Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Thomas Törnblom via TF-M Sent: Tuesday, April 28, 2020 4:58 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] REGION_DECLARE macros I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software. Trying another type: /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); Den 2020-04-28 kl. 10:51, skrev Thomas Tï¿½rnblom via TF-M: With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains. Example diff: --- ï¿½ï¿½ï¿½ï¿½ /* Set Main Stack Pointer limit */ -ï¿½ï¿½ï¿½ extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; -ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); +ï¿½ï¿½ï¿½ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,ï¿½ $$ZI$$Base); +ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, +ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ $$ZI$$Base)); --- 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> -- 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, 10 months

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by Thomas Törnblom

I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software. Trying another type: /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); Den 2020-04-28 kl. 10:51, skrev Thomas Törnblom via TF-M: > With the integration of the IAR toolchain support in TF-M it has > become important to use the REGION_DECLARE/REGION_NAME macros in > platform/region.h instead of using symbols like > "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". > > The IAR linker can not use these symbols and the macros in combination > with the IAR specific cmake rules creates appropriate symbols for all > the supported toolchains. > > Example diff: > --- > ï¿½ï¿½ï¿½ï¿½ /* Set Main Stack Pointer limit */ > -ï¿½ï¿½ï¿½ extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; > -ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); > +ï¿½ï¿½ï¿½ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,ï¿½ $$ZI$$Base); > +ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, > +ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > $$ZI$$Base)); > --- > > 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> > -- *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, 10 months

1
0
0 0

REGION_DECLARE macros

by Thomas Törnblom

With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains. Example diff: --- /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); --- 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, 10 months

1
0
0 0

Questions on TFM_NS_CLIENT_IDENTIFICATION

by Reinhard Keil

I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled. However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime. Reinhard

5 years, 10 months

1
0
0 0

Re: [TF-M] Documentation for platform interfaces

by Minos Galanakis

Hi Reinhard I think the closer to a high level documentation is this page: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… To your question regarding the nv counters, they are currently used by MCUBOOT and Protected Storage Service. You may be interested in this patch under review which is will expose them as a service https://review.trustedfirmware.org/c/trusted-firmware-m/+/3367 Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Reinhard Keil via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 April 2020 16:07 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Documentation for platform interfaces 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

2
1
0 0

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

by Ken Liu

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> On Behalf Of Anton Komlev via TF-M Sent: Thursday, April 23, 2020 3:29 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)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, 10 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M