- TF-M - lists.trustedfirmware.org

Slight update on design proposal process document

by Ken Liu

Hi, I have made a slight update on the design proposal process document, to simplify the design document drafting. The 'Author' and 'Organization' are not both mandatory, one of them can be optional depends on the contributor. And mark the 'status' optional since it can be covered by the document system. Feel free to comment on the patch: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3407 And I prefer to comment on the issue link since there is more better for discussion: https://developer.trustedfirmware.org/T673 Reply here is an option, too. BR /Ken

5 years, 7 months

1
1
0 0

TF-M v1.0 is released

by Anton Komlev

Dear All, Happy to announce that Trusted Firmware - M project has reached the important milestone of v1.0. The major features covered in this release are : * PSA Level 1 & Level 2 certification requirements as updatable RoT * Support for PSA Dev APIs (PS, ITS, Attestation) aligned to PSA 1.0 specs, and Crypto aligned to 1.0-beta-3 * Reference implementation on various platforms * Arm : Musca-A, Musca-B1, Musca-S1, FPGAs , FVPs * Cypress PSoC6 * ST's STM32L5 and NXP's LPC55S69 are coming soon All release details are in the changelog file: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/changelog.… A Rendered HTML version is here: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… This is the result of great collaboration between multiple organizations toward a single common goal - to make firmware secure and trustful. Thanks all direct and indirect contributors who devoted their time and efforts to make this happen. Anton Komlev TF-M Technical Leader Arm Ltd.

5 years, 7 months

1
0
0 0

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

by Shreve, Erik

Ken, Thanks for the feedback! I agree that care will be needed in the design and implementation of the calls from S to NS. I hope to provide design details that minimize the risk by minimizing the RTOS specific layer. Unfortunately, I'm not clear on your feedback about the 'scheduler' and 'context-switch' terms. Let me expand on my proposal here a bit more. Perhaps this will clarify things or at least provide enough detail for you to provide more specific feedback. I'm sure you are aware that the PSA Firmware Framework provides for the scheduling of the secure partitions. I'm proposing (as an option, it is not a core feature of the proposal) that the SPM may be responsible for scheduling of Application Root of Trust services in this new model. Further, execution of PSA RoT services on behalf of Application RoT services may also fall under the SPM's scheduling. Thus, this part of the new model would fit with the PSA FF spec. This would thus mean that the NSPE RTOS is only scheduling NSPE Tasks and the associated PSA RoT service requests for those NSPE Tasks. However, supporting the "App RoT scheduling by SPM" in the model may complicate the implementation or at the very least the straightforward understanding of how the model works. The alternative, of course, is that the NSPE RTOS schedules the execution of the Application RoT services the same as it schedules the PSA RoT services. I think I prefer the latter, but I'm open to the former if the community has good reasons for it. One reason might be an expectation that PSA RoT services will be maintained by platform owners and platform owners can choose which models to support, but the community may want creators of Application RoT services to have the same experience regardless of the model implemented. Thanks! Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M Sent: Monday, March 23, 2020 9:49 PM To: 'tf-m(a)lists.trustedfirmware.org' Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal Hi Erik, This is a good proposal, thanks. And I got two comments in your listed bullets: * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) - Even the Trustzone-M supports S to NS call, be cation when you are designing such features because leave a waiting pattern in the secure side exposes one extra interface. * A SPE scheduler may still exist for application root of trust services, if any exist on a system. - Please use the 'scheduler' and 'context-switch' with scope. If there are 2 threads only and just switching contexts between them, the word 'scheduler' would be a bit confusing here. Hope my assumption is incorrect. Please go ahead with your preparation for the Tech Forum. Anton can give you detail descriptions about it and I think preparing a PUBLIC slide can be the first step. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Tuesday, March 24, 2020 5:26 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal Anton, Yes, I can be prepared to discuss in the next forum. (I believe you are referring to the one on April 2nd). I've not participated in the forums yet, please send me some information as to the format/rules/etc. Thanks! Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Anton Komlev via TF-M Sent: Monday, March 23, 2020 3:39 PM To: 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 Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

2
1
0 0

Invitation: TF-M Tech Forum @ Thu 2 Apr 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum After a discussion on the mailing list we have moved the timeslot this week to give an opportunity for US participants to join.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: Thu 2 Apr 2020 16:00 – 17:00 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=NmY2dWZkbzZtMjZyNHNmb… 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, 7 months

1
0
0 0

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

by David Wang

That sounds good! Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, March 24, 2020 1:46 AM To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - April 2 Hi Jamie, Thanks for noticing. You are right, that time would be better so the new proposal is 15.00 UTC. I have reused the time from the last session but forgot about the time change. Here anyone can play with the time zones: https://www.timeanddate.com/worldclock/meetingtime.html?day=2&month=4&year=… Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 2 April 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, 2 April 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, 2 April 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, 2 April 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 2 April 2020, 15:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200402T1500> Best regards, Anton From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: 23 March 2020 17:29 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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 Technical Forum call - April 2 Hi Anton, As we will have moved to daylight saving time in US and Europe, it seems like 15.00 UTC could be a good compromise for this next session. Would result in 8.00 west coast/10.00 central/11.00 east/16.00 UK/17.00 Europe/23.00 China. So good times for US/Europe and still possible for China to join if anyone really wants to. What do you think? Kind regards, Jamie 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: 23 March 2020 14:30 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 2 Hello, Last 3 sessions of the Tech Forum were convenient for Europe – Asia time zones, where majority of participants are. To let US members a chance to join at a reasonable time, propose to have the next session at US-friendly time (17:00 UTC) and then keep it every 4th, having 1:3 ratio. What do you think about such schema? As usual, please reply to this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 7 months

1
0
0 0

Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hello all, As the developers community at trustedfirmware.org is growing, there is an increasing need to have work processes that are clearly documented, feel smooth and scale well. We think that there is an opportunity to improve the way the trustedfirmware.org projects are managed today. That's why we are sharing a project maintenance proposal, focusing on the TF-A and TF-M projects initially. The aim of this document is to propose a set of rules, guidelines and processes to try and improve the way we work together as a community today. Note that this is an early draft at this stage. This is put up for further discussion within the trustedfirmware.org community. Nothing is set in stone yet and it is expected to go under change as feedback from the community is incorporated. Please find the initial proposal here: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Please provide any feedback you may have by replying to this email thread, keeping all 4 mailing lists in the recipients list. I will collate comments from the community and try to incorporate them in the document, keeping you updated on changes made between revisions. Regards, Sandrine

5 years, 7 months

1
0
0 0

Re: [TF-M] TF-M Profile Small design document under review

by Andrej Butok

Hi David, I have attached the Mbed-Crypto configuration file, which enables only minimum set of crypto algorithms required to pass the current TFM regression tests. It saves us about 30KB of ROM if to compare to the default TFM settings. Hope, it can be useful for others. Regards, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, March 24, 2020 7:37 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Profile Small design document under review Hi all, Could you please help review the latest design document of TF-M Profile Small (previously named as Profile 1)? TF-M Profile Small provides a predefined list of features with small memory footprint, on ultra-constrained device. Major changes since last version: * Renamed as Profile Small to avoid confusing readers with other similar terms. The other profiles will be named as Profile Medium and Profile Large. * Enable symmetric key algorithms based Initial Attestation. Please help review the document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> for more details. The corresponding implementation patch set is also updated on https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. Any suggestion or comment is welcome! Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Friday, March 6, 2020 4:47 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 Profile 1 design document under review Hi all, As we discussed in Tech Forum yesterday, we proposed the TF-M Profile 1 design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. Any comment, suggestion or question is welcome. We will keep updating and finalizing the document. The corresponding TF-M Profile 1 implementation patch set is also under review on https://review.trustedfirmware.org/q/topic:%22profile-1-config%22+(status:o…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. Best regards, Hu Ziji

5 years, 7 months

2
1
0 0

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

by Anton Komlev

Hi Erik, Right, I had in mind the next forum on Apr 2, which is planned for US time zone. Invitations will be send soon having no more ideas or objection on the time slot. The forum format is open and quite unformal. You can find the recordings of all sessions here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ I would suggest to have few slides with the concept for idea introduction and references during discussion. All the best, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 21:26 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal Anton, Yes, I can be prepared to discuss in the next forum. (I believe you are referring to the one on April 2nd). I've not participated in the forums yet, please send me some information as to the format/rules/etc. Thanks! Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Anton Komlev via TF-M Sent: Monday, March 23, 2020 3:39 PM To: 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 Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

1
0
0 0

TF-M Profile Small design document under review

by David Hu

Hi all, Could you please help review the latest design document of TF-M Profile Small (previously named as Profile 1)? TF-M Profile Small provides a predefined list of features with small memory footprint, on ultra-constrained device. Major changes since last version: * Renamed as Profile Small to avoid confusing readers with other similar terms. The other profiles will be named as Profile Medium and Profile Large. * Enable symmetric key algorithms based Initial Attestation. Please help review the document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598 for more details. The corresponding implementation patch set is also updated on https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o…. Any suggestion or comment is welcome! Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Friday, March 6, 2020 4:47 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Profile 1 design document under review Hi all, As we discussed in Tech Forum yesterday, we proposed the TF-M Profile 1 design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Any comment, suggestion or question is welcome. We will keep updating and finalizing the document. The corresponding TF-M Profile 1 implementation patch set is also under review on https://review.trustedfirmware.org/q/topic:%22profile-1-config%22+(status:o…. Best regards, Hu Ziji

5 years, 7 months

1
0
0 0

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

by Ken Liu

Hi Erik, This is a good proposal, thanks. And I got two comments in your listed bullets: * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) - Even the Trustzone-M supports S to NS call, be cation when you are designing such features because leave a waiting pattern in the secure side exposes one extra interface. * A SPE scheduler may still exist for application root of trust services, if any exist on a system. - Please use the 'scheduler' and 'context-switch' with scope. If there are 2 threads only and just switching contexts between them, the word 'scheduler' would be a bit confusing here. Hope my assumption is incorrect. Please go ahead with your preparation for the Tech Forum. Anton can give you detail descriptions about it and I think preparing a PUBLIC slide can be the first step. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Tuesday, March 24, 2020 5:26 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal Anton, Yes, I can be prepared to discuss in the next forum. (I believe you are referring to the one on April 2nd). I've not participated in the forums yet, please send me some information as to the format/rules/etc. Thanks! Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Anton Komlev via TF-M Sent: Monday, March 23, 2020 3:39 PM To: 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 Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

1
0
0 0

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

by Shreve, Erik

Anton, Yes, I can be prepared to discuss in the next forum. (I believe you are referring to the one on April 2nd). I've not participated in the forums yet, please send me some information as to the format/rules/etc. Thanks! Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Anton Komlev via TF-M Sent: Monday, March 23, 2020 3:39 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

1
0
0 0

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

by Anton Komlev

Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

1
0
0 0

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

by Jamie Fox

Hi Anton, As we will have moved to daylight saving time in US and Europe, it seems like 15.00 UTC could be a good compromise for this next session. Would result in 8.00 west coast/10.00 central/11.00 east/16.00 UK/17.00 Europe/23.00 China. So good times for US/Europe and still possible for China to join if anyone really wants to. What do you think? Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 23 March 2020 14:30 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - April 2 Hello, Last 3 sessions of the Tech Forum were convenient for Europe - Asia time zones, where majority of participants are. To let US members a chance to join at a reasonable time, propose to have the next session at US-friendly time (17:00 UTC) and then keep it every 4th, having 1:3 ratio. What do you think about such schema? As usual, please reply to this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 7 months

2
1
0 0

TF-M Technical Forum call - April 2

by Anton Komlev

Hello, Last 3 sessions of the Tech Forum were convenient for Europe - Asia time zones, where majority of participants are. To let US members a chance to join at a reasonable time, propose to have the next session at US-friendly time (17:00 UTC) and then keep it every 4th, having 1:3 ratio. What do you think about such schema? As usual, please reply to this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 7 months

1
0
0 0

Multi-threaded single-scheduler model proposal

by Shreve, Erik

I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

1
0
0 0

Trusted Firmware Keynote @Linaro TechDays (Wed 25 Mar, 16:00-16:30 GMT)

by Shebu Varghese Kuriakose

Hi All, Trusted Firmware will be opening the Linaro Tech Days event on Wed 25th March at 4pm (16:00) GMT with a keynote presenting all the latest exciting news from the project. https://connect.linaro.org/resources/ltd20/ltd20-200k/ and, once registered, on sched: https://linarotechdays.sched.com/event/ZZFK/ltd20-200k-keynote-trusted-firm… The session will be live streamed and recorded (links in the above resources) and slides will be attached there too. Don't miss it! Regards, Shebu/Matteo

5 years, 7 months

1
0
0 0

Re: [TF-M] psa-arch-tests console baud rate

by Edison Ai

Hi Thomas, For your 2nd question. I have tested it on my side and it has the same problem. The TF-M can print normal boot message, but the log becomes garbage after enter into Arch test. The PSA Arch test is another independent project, and I have arisen this issue to the PSA Arch test project: https://github.com/ARM-software/psa-arch-tests/issues/164. You can watch this issue directly. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M Sent: Thursday, March 19, 2020 9:54 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] psa-arch-tests console baud rate Hi Thomas, Thanks your mail. For your 1st question. There is indeed a problem to build the PSA arch crypto test on the Musca_a board for the RAM size is too small. I suggest you split the crypto tests into different test images on the Musca_a board. For the 2nd question, I only test that on FVP AN521 but never met this problem. We will test that on the MPS2 AN521 board soon to check if it is a real problem. If yes, we will try to fix that quickly. Thanks, Edison 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: Wednesday, March 18, 2020 9:38 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] psa-arch-tests console baud rate Triggered by Rays mail on slow RSA key pair generation, I built and tried to run the tests, but ran into a couple of issues: 1) I attempted to build it for the Musca A, but apparently that doesn't have enough RAM to run these tests 2) Switching to an MPS2+ with AN521 configuration I see that the baud rate on the UART appears wrong when running the tests. mcuboot produces correct messages at 115200 bps, as does the normal ConfigRegression* tests, but the ConfigPsaApiTest* appears to produce just garbage. Is there a setting I need to set to get any useful data on the terminal when running the ConfigPsaApiTests? Cheers, 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, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: SPM_IDLE

by DeMars, Alan

Ken, Our secure callback solution to this issue is working. I am just following up to understand what the SPM_IDLE concept is. Alan On Mar 20, 2020, at 4:34 AM, Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: Hi Alan, Looks like this is the still classic case, but unfortunately that there is no defined design at the current stage. Heard you were working on an solution for this, and got some issues when non-secure preempts secure execution, since your scheduler works in thread mode so cannot update secure context while scheduling – please correct me if my understanding is wrong. Is this mail a follow up or another thread just focus on discussion of the cooperative scheduling document? BR /Ken From: DeMars, Alan <ademars(a)ti.com> Sent: Friday, March 20, 2020 2:27 AM To: Ken Liu <Ken.Liu(a)arm.com> Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: RE: SPM_IDLE Ken, Our use case is to support a “secure driver”: 1. A peripheral can only be accessed in secure mode. 2. The peripheral is configured and a hardware process is triggered within the peripheral. 3. When the process completes, a secure interrupt is triggered. 4. The NS thread that is using this driver should block (allowing other NS threads to run) while waiting for the hardware process to complete and resume when the process is finished. Alan From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M Sent: Thursday, March 5, 2020 10:28 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] SPM_IDLE Hi Alan, It (8.3.5) is one of the cases can be dealt with, and now it is not detail defined yet. Can you describe what your practical purpose for S/NS interactive is so that we could collect feedbacks to check if the rules are applicable? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, March 4, 2020 10:51 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] SPM_IDLE Mention is made to “SPM_IDLE” in the Cooperative Scheduling Rules document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… I’m struggling to understand section 8.3.5 which references SPM_IDLE but doesn’t really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Interface: Remove unused header include

by Devaraj Ranganna

Hi, The patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3620 removes the header `tfm_veneers.h` from PSA IPC API source files. If there are no objects then can this patchset be merged? Thanks, Dev 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, 7 months

1
0
0 0

Re: [TF-M] SPM_IDLE

by DeMars, Alan

Ken, Our use case is to support a "secure driver": 1) A peripheral can only be accessed in secure mode. 2) The peripheral is configured and a hardware process is triggered within the peripheral. 3) When the process completes, a secure interrupt is triggered. 4) The NS thread that is using this driver should block (allowing other NS threads to run) while waiting for the hardware process to complete and resume when the process is finished. Alan From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M Sent: Thursday, March 5, 2020 10:28 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SPM_IDLE Hi Alan, It (8.3.5) is one of the cases can be dealt with, and now it is not detail defined yet. Can you describe what your practical purpose for S/NS interactive is so that we could collect feedbacks to check if the rules are applicable? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, March 4, 2020 10:51 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SPM_IDLE Mention is made to "SPM_IDLE" in the Cooperative Scheduling Rules document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… I'm struggling to understand section 8.3.5 which references SPM_IDLE but doesn't really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called. Alan

5 years, 7 months

2
1
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Raymond Ngun

Thanks Tamas, Did you try with CC312 disabled as well? I am wondering if you would be able to at least reproduce what I saw. Ray From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Thursday, March 19, 2020 4:30 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] FW: 2048-bit RSA Keypair generation is slow CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, We did measurements on Musca-B1 with enabled CC312. We did 10 run with both compiler( armclang and gnuarm). RSA2048 key generation takes 10-35 sec. In average gnuarm seems a bit slower. I suspect the reason behind that random number still need to be tested that are they fit for rsa2048 generation (might are they primes?) and the testing algorithm is might faster with armclang. But for sure we have not seen any run which could take minutes. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M Sent: 19 March 2020 12:17 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That's all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.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: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn't test Musca-B1 with cc312 enabled and I don't have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn't always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I've seen it finish quickly (less than a minute) but I've also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.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: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? 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. 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. 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, 7 months

1
0
0 0

Re: [TF-M] psa-arch-tests console baud rate

by Edison Ai

Hi Thomas, Thanks your mail. For your 1st question. There is indeed a problem to build the PSA arch crypto test on the Musca_a board for the RAM size is too small. I suggest you split the crypto tests into different test images on the Musca_a board. For the 2nd question, I only test that on FVP AN521 but never met this problem. We will test that on the MPS2 AN521 board soon to check if it is a real problem. If yes, we will try to fix that quickly. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, March 18, 2020 9:38 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] psa-arch-tests console baud rate Triggered by Rays mail on slow RSA key pair generation, I built and tried to run the tests, but ran into a couple of issues: 1) I attempted to build it for the Musca A, but apparently that doesn't have enough RAM to run these tests 2) Switching to an MPS2+ with AN521 configuration I see that the baud rate on the UART appears wrong when running the tests. mcuboot produces correct messages at 115200 bps, as does the normal ConfigRegression* tests, but the ConfigPsaApiTest* appears to produce just garbage. Is there a setting I need to set to get any useful data on the terminal when running the ConfigPsaApiTests? Cheers, 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, 7 months

1
0
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Adrian Shaw

Note that you'll still to re-seed from the TRNG periodically, but doesn't have to be done every time the application needs a random number. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 19 March 2020 11:16 To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; Soby Mathew <Soby.Mathew(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That’s all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn’t test Musca-B1 with cc312 enabled and I don’t have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn’t always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I’ve seen it finish quickly (less than a minute) but I’ve also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.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: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I’ve run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I’ve seen it take even longer – I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? 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. 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, 7 months

1
0
0 0

FW: 2048-bit RSA Keypair generation is slow

by Tamas Ban

Hi, We did measurements on Musca-B1 with enabled CC312. We did 10 run with both compiler( armclang and gnuarm). RSA2048 key generation takes 10-35 sec. In average gnuarm seems a bit slower. I suspect the reason behind that random number still need to be tested that are they fit for rsa2048 generation (might are they primes?) and the testing algorithm is might faster with armclang. But for sure we have not seen any run which could take minutes. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M Sent: 19 March 2020 12:17 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That's all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.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: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn't test Musca-B1 with cc312 enabled and I don't have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn't always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I've seen it finish quickly (less than a minute) but I've also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.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: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? 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. 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, 7 months

1
0
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Adrian Shaw

If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That’s all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn’t test Musca-B1 with cc312 enabled and I don’t have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn’t always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I’ve seen it finish quickly (less than a minute) but I’ve also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.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: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I’ve run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I’ve seen it take even longer – I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? 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. 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, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M