- TF-M - lists.trustedfirmware.org

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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 9 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, 9 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, 9 months

1
0
0 0

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

by Soby Mathew

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> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)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.

5 years, 9 months

2
2
0 0

psa-arch-tests console baud rate

by Thomas Törnblom

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

1
0
0 0

2048-bit RSA Keypair generation is slow

by Raymond Ngun

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.

5 years, 9 months

1
0
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Shreve, Erik

Thanks, The library model seems to treat the entire SPE as a single resource as it appears to lock and only allow a single entry at a time: /* This is the "Big Lock" on the secure side, to guarantee single entry * to SPE */ extern int32_t tfm_secure_lock; Is this a limitation of the current implementation or is this the envisioned design for the library model? If the latter, is there a technical/security reason why only a single entry is allowed? Or is it that no use-case to allow multiple entry has been discussed. To back up a bit, we have use cases where I would like to see the NSPE RTOS make all the scheduling decisions and further have all the secure peripheral resources be managed individually with respect to blocking threads. The IPC model seems to be built around having a scheduler in the SPM and the library model seems to preclude the ability to manage secure peripherals individually. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Friday, March 13, 2020 7:50 AM To: Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Yes, the two working models are mutually exclusive, and the model is selected compile time, by choosing a corresponding config cmake file. I'm afraid there isn't a comprehensive specification for the Library model, like for IPC model. For examples on calling services in library model, you can have a look in the Secure Service API implementations. Look in interface/src for NS, and in the directory of the services, for example services/initial_attestation/tfm_attestation_secure_api.c for secure examples. The working model specific code parts that are in common files are (across the whole TF-M codebase) guarded by the TFM_PSA_API define: #ifdef TFM_PSA_API /* IPC model implementation */ #else /* TFM_PSA_API */ /* Library model implementation */ #endif /* TFM_PSA_API */ If a source file is IPC model specific it has 'ipc' in its name, or is in a directory called 'ipc'. Library model specific files have 'func' in their name. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Friday, March 13, 2020 1:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Mate, Thanks for providing your time to respond. Understanding there are two models in play helps a lot. A few follow up questions... Can you confirm that the models are mutually exclusive? This page indicates to me that they are mutually exclusive: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Or are there provisions to allow a system to run both models on the _same_ execution node? For example running both on the same v7 or v8 with TrustZone core. If there are provisions for this, where can I go to get a better understanding of them? Also, is there any spec for the library model beyond the API descriptions in the CMSIS documentation (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT… If not, then I'll rely on reading the existing code. Please feel free to point me more documentation if I can get answers there. (I don't mind a friendly "read the manual" or "run this example code.") Thanks again for your time. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday, March 12, 2020 2:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate 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: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here. I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks. I found the following: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything. Am I missing something? I'd like to understand more about where TFM is going with the tz_context interface. Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not. I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution. Are there other documents I can read or source implementations I can reference to get more of a handle on this? Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments

5 years, 9 months

2
1
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Mate Toth-Pal

Hi Erik, Yes, the two working models are mutually exclusive, and the model is selected compile time, by choosing a corresponding config cmake file. I'm afraid there isn't a comprehensive specification for the Library model, like for IPC model. For examples on calling services in library model, you can have a look in the Secure Service API implementations. Look in interface/src for NS, and in the directory of the services, for example services/initial_attestation/tfm_attestation_secure_api.c for secure examples. The working model specific code parts that are in common files are (across the whole TF-M codebase) guarded by the TFM_PSA_API define: #ifdef TFM_PSA_API /* IPC model implementation */ #else /* TFM_PSA_API */ /* Library model implementation */ #endif /* TFM_PSA_API */ If a source file is IPC model specific it has 'ipc' in its name, or is in a directory called 'ipc'. Library model specific files have 'func' in their name. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Friday, March 13, 2020 1:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Mate, Thanks for providing your time to respond. Understanding there are two models in play helps a lot. A few follow up questions... Can you confirm that the models are mutually exclusive? This page indicates to me that they are mutually exclusive: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Or are there provisions to allow a system to run both models on the _same_ execution node? For example running both on the same v7 or v8 with TrustZone core. If there are provisions for this, where can I go to get a better understanding of them? Also, is there any spec for the library model beyond the API descriptions in the CMSIS documentation (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT… If not, then I'll rely on reading the existing code. Please feel free to point me more documentation if I can get answers there. (I don't mind a friendly "read the manual" or "run this example code.") Thanks again for your time. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday, March 12, 2020 2:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate 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: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here. I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks. I found the following: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything. Am I missing something? I'd like to understand more about where TFM is going with the tz_context interface. Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not. I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution. Are there other documents I can read or source implementations I can reference to get more of a handle on this? Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments

5 years, 9 months

1
0
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Shreve, Erik

Mate, Thanks for providing your time to respond. Understanding there are two models in play helps a lot. A few follow up questions... Can you confirm that the models are mutually exclusive? This page indicates to me that they are mutually exclusive: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Or are there provisions to allow a system to run both models on the _same_ execution node? For example running both on the same v7 or v8 with TrustZone core. If there are provisions for this, where can I go to get a better understanding of them? Also, is there any spec for the library model beyond the API descriptions in the CMSIS documentation (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT… If not, then I'll rely on reading the existing code. Please feel free to point me more documentation if I can get answers there. (I don't mind a friendly "read the manual" or "run this example code.") Thanks again for your time. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday, March 12, 2020 2:34 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here. I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks. I found the following: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything. Am I missing something? I'd like to understand more about where TFM is going with the tz_context interface. Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not. I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution. Are there other documents I can read or source implementations I can reference to get more of a handle on this? Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments

5 years, 9 months

1
0
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Mate Toth-Pal

Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here. I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks. I found the following: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything. Am I missing something? I'd like to understand more about where TFM is going with the tz_context interface. Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not. I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution. Are there other documents I can read or source implementations I can reference to get more of a handle on this? Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments

5 years, 9 months

1
0
0 0

Re: [TF-M] NS DATA Linker file

by Mate Toth-Pal

Hi Andrej, You seem to be right. In the current platforms NS_DATA_SIZE is defined as either of the following: * #define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE) * #define NS_DATA_SIZE (TOTAL_RAM_SIZE / 2) Which means NS_DATA_SIZE Is the maximum available RAM for the NS Software. So the maximum available size of the RW and ZI data is decreased by the amounts you enumerate in your mail. I created a task to fix this: https://developer.trustedfirmware.org/T687 Thanks, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Thursday, March 12, 2020 9:23 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] NS DATA Linker file Hello, It looks like there is a mistake for ER_DATA region in the NS armclang linker file. ... ER_DATA NS_DATA_START NS_DATA_SIZE { * (+ZI +RW) } /* MSP */ ARM_LIB_STACK_MSP +0 ALIGN 32 EMPTY NS_MSP_STACK_SIZE { } /* PSP */ ARM_LIB_STACK +0 ALIGN 32 EMPTY NS_PSP_STACK_SIZE { } ARM_LIB_HEAP +0 ALIGN 8 EMPTY NS_HEAP_SIZE { } ... ER_DATA does not take into account the NS_MSP_STACK_SIZE+NS_PSP_STACK_SIZE+EMPTY NS_HEAP_SIZE size: #define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE) Guess, the NS linker file should be: ... ER_DATA NS_DATA_START NS_DATA_SIZE-NS_MSP_STACK_SIZE-NS_PSP_STACK_SIZE-EMPTY NS_HEAP_SIZE { * (+ZI +RW) } ... Or, did I miss something? Thank you, Andrej Butok

5 years, 9 months

1
0
0 0

Re: [TF-M] PSA Test Suite - Attestation test

by Andrej Butok

Hi Tamas, I have noticed today, that the PSA test suite has done several merges to its master branch. Based the PSA test-suit readme, it has switched to newer versions of the PSA API. Should we try to update or better to wait for a right signal from the TFM team? Thanks, Andrej From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Sent: Thursday, February 6, 2020 2:09 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Subject: RE: PSA Test Suite - Attestation test Hi Andrej, The v19.08_TBSA0.9 version of psa-arch test suite is aligned with current TF-M master. I have executed the test suite and found that unfortunately the attestation test suite is currently broken: * It was introduced by the QCBOR library update in https://review.trustedfirmware.org/c/trusted-firmware-m/+/2679/6<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * Currently there is a misalignment between psa-arch and tf-m in terms of QCBOR version. psa-arch still relies on older version of QCBOR. * The version mismatch lead some parsing error in CBOR that is the reason why the test suite is failing. * Other issue is that v19.08_TBSA0.9 version of psa-arch mandates the key-id in unprotected COSE header, however that field is optional according to the standard. In TF-M the inclusion of key-id was bind to ATTEST_INCLUDE_TEST_CODE_AND_KEY_ID, which was split to two compile time switch (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3147<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>) ATTEST_INCLUDE_COSE_KEY_ID and ATTEST_ INCLUDE_TEST_CODE. Way forward: * I let the psa-arch test team to update QCBOR. * Fix will be put on master, but currently the tip of the psa-arch master is not aligned with TF-M master. They are supports different PSA API versions. * In TF-M there is a branch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> where the PSA API update is happening. This branch is intended to be merged to master in Q1. Tamas From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 05 February 2020 14:21 To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: PSA Test Suite - Attestation test Hi Tamas > Could you tell what was the values of these compile time switches in your test? For the previous TFM, we have used INCLUDE_TEST_CODE_AND_KEY_ID. For the current TFM it was renamed to INCLUDE_TEST_CODE. Other parameters are new, so I have tried different combinations of these parameters, but the PSA Test-Suite Attestation is still failed. > Further do you implemented the boot data sharing between bootloader and runtime firmware? It's used the TFM template code without change from tfm\platform\ext\common\template > Do you sign SPE and NPSE images together or they are signed separately? We do not use the secondary bootloader so far, so image is not signed. As the Attestation Regression tests are passed. It's good to know what combination of parameters have to be used to generate the same token as it was generated by the older TFM and accepted by the PSA Test Suite (last commit on master branch). Or the PSA Test Suite is obsolete. Thank you, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Tamas Ban via TF-M Sent: Wednesday, February 5, 2020 1:13 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] PSA Test Suite - Attestation test Hi Andrej, Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 04 February 2020 17:33 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA Test Suite - Attestation test Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 9 months

2
3
0 0

Re: [TF-M] TF-M Technical Forum call - March 19

by Mate Toth-Pal

Hi All, I would like to give a short talk about a tool proposal to test IRQ handling in TF-M core. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, March 11, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - March 19 Hello, The next Technical Forum is planned on Thursday, March 19 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 9 months

1
0
0 0

NS DATA Linker file

by Andrej Butok

Hello, It looks like there is a mistake for ER_DATA region in the NS armclang linker file. ... ER_DATA NS_DATA_START NS_DATA_SIZE { * (+ZI +RW) } /* MSP */ ARM_LIB_STACK_MSP +0 ALIGN 32 EMPTY NS_MSP_STACK_SIZE { } /* PSP */ ARM_LIB_STACK +0 ALIGN 32 EMPTY NS_PSP_STACK_SIZE { } ARM_LIB_HEAP +0 ALIGN 8 EMPTY NS_HEAP_SIZE { } ... ER_DATA does not take into account the NS_MSP_STACK_SIZE+NS_PSP_STACK_SIZE+EMPTY NS_HEAP_SIZE size: #define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE) Guess, the NS linker file should be: ... ER_DATA NS_DATA_START NS_DATA_SIZE-NS_MSP_STACK_SIZE-NS_PSP_STACK_SIZE-EMPTY NS_HEAP_SIZE { * (+ZI +RW) } ... Or, did I miss something? Thank you, Andrej Butok

5 years, 9 months

1
0
0 0

Cooperative Scheduling Rules and CMSIS tz_context

by Shreve, Erik

Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here. I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks. I found the following: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything. Am I missing something? I'd like to understand more about where TFM is going with the tz_context interface. Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not. I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution. Are there other documents I can read or source implementations I can reference to get more of a handle on this? Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments

5 years, 9 months

1
0
0 0

TF-M Technical Forum call - March 19

by Anton Komlev

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

5 years, 9 months

1
0
0 0

Re: [TF-M] Product Lifecycle Management: TF-M + Non-Secure Application

by Tamas Ban

Hi, TF-M version information is carried by manifest data, which is appended to the image in a post build step (at image signing): * Image header: Contains image actual version: 1.0.0 * Image TLV (footer): Can contains a dependency TLV entry which refers to the dependent image by an ID and its minimum version. Dependency verification: * At boot time the bootloader checks whether the dependency would be satisfies after a software upgrade. If not then it deny the update. * https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/user_guide… At runtime there is no API to get the image version or its capability. Did I answer your question? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 09 March 2020 09:45 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Product Lifecycle Management: TF-M + Non-Secure Application Hi, How does TF-M consider Product Lifecycle Management (PLM)? Assuming the following scenario where TF-M and Non-Secure Application are independently developed/updated in a deployed system: * TF-M is delivered i.e. by a silicon vendor in a pre-configured variant and Non-Secure Application starts to use this configuration. * During PLM there is a decision to update/upgrade/downgrade TF-M. The new image is pushed to deployed devices independent of Non_Secure application. Questions that I have: * Is there a way for the Non-Secure application to identify the functionality available in TF-M? * How is it ensured that new TF-M versions are compatible with previous versions? Reinhard

5 years, 9 months

1
0
0 0

TrustZone initialisation procedure

by Reinhard Keil

Abhishek, A few days, I posted the reasons why MPC/PPC should not be used for level 3 isolation. Did you had a chance to read that? MPC/PPC implement system wide isolation. IMHO, reprogramming it for level 3 isolation should be not considered as it creates various problems for the system designer. You did also ask, how to ensure that security is actually enabled, basically if security has been initalized. The best approach would be to check if the SAU->CTRL is correctly set; if not the system should shut down. Reinhard

5 years, 9 months

2
1
0 0

Product Lifecycle Management: TF-M + Non-Secure Application

by Reinhard Keil

Hi, How does TF-M consider Product Lifecycle Management (PLM)? Assuming the following scenario where TF-M and Non-Secure Application are independently developed/updated in a deployed system: * TF-M is delivered i.e. by a silicon vendor in a pre-configured variant and Non-Secure Application starts to use this configuration. * During PLM there is a decision to update/upgrade/downgrade TF-M. The new image is pushed to deployed devices independent of Non_Secure application. Questions that I have: * Is there a way for the Non-Secure application to identify the functionality available in TF-M? * How is it ensured that new TF-M versions are compatible with previous versions? Reinhard

5 years, 9 months

1
0
0 0

Re: [TF-M] TrustZone initialisation procedure

by Reed Hinkel

We need to be cognizant of the target usage and user base. The vast majority of usage is v8m in which case the HAL can be simple and targeted for TrustZone. Based on what I have witnessed other than the changes required to support dual/multicore usage. Why not offer a HAL option for TrustZone and one for dual/multicore? All the best! Reed From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Abhishek Pandit via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Date: Friday, March 6, 2020 at 4:28 AM To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TrustZone initialisation procedure Hi, I see this slight differently. The purpose of TF-M HAL is to abstract out specific HW dependencies from the SW framework for creating isolated secure partitions. As you can understand, various systems have differences in what components are utilized for isolation, but TF-M needs to implement a generic mechanism that works across multiple platforms. Therefore it’s important to consider what’s platform specific and what’s generic. In that sense, SAU and other system components are specific to the underlying HW hence should be part of platform implementation. Of course, it is possible to implement a unified HAL for a family of devices, however I would still expect the hardware abstraction layer in TF-M to remain agnostic of how the HW implements/facilitates isolation of secure world. I don’t disagree with the suggestion about enhancements but they seem platform specific to me so should be discussed in that context. Thanks, Abhishek From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 04 March 2020 03:14 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TrustZone initialisation procedure Hi Jonatan, The enhancement of this TZ_SAU_Setup() sounds reasonable, and there are more background items to be considerate: * The SPM need to re-configure the isolation hardware dynamically under isolation level 3 while SPM scheduling, and MPC/PPC is potentially included. So I am not sure what the ‘system isolation’ mean in your mail, if you want a static initialization for all isolation settings then it will not work for SPM at least for the isolation level 3 design. If it includes the minimal security (and fundamental) setting while system booting and there are other functions to update the isolation setting later, it is do-able. * How does the parameter pass into this function? Because SPM needs to know the status of the existing isolation setting for some purposes (such as security checking), so there needs to be a way to let SPM know the isolation status. So if we do the fundamental security setup in SystemInit(), the advantage is the protection is already enabled between SystemInit() exits and SPM_Init() (There are platform init process in this stage). The cons are SPM may not check the isolation status. And if we do isolation in SPM_Init(), the advantage is SPM can know the status and the cons are Platform Init is not restricted (It could access anywhere). I would suggest not to propose the calling time strictly for this new enhanced API. I know cypress uses customized protection initialization mechanism so any ideas? BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jonatan Antoni via TF-M Sent: Tuesday, March 3, 2020 11:09 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] TrustZone initialisation procedure Hi all, I am trying to align TrustZone initialisation procedure between TF-M and CMSIS. In CMSIS the approach from the early v8-M days is to have a “partition.h” file providing “TZ_SAU_Setup()” function. This function is called during low level “SystemInit()” which runs as part of the pre-main (called from ResetHandler and before running C lib init). In contrast TF-M calls “tfm_spm_hal_init_isolation_hw()” (which is similar to “TZ_SAU_Setup()” plus PPC/MPC configuration) during “tfm_core_init()” (which runs in secure “main()”). The advantage of “TZ_SAU_Setup()” is that this function is available by standard for all TrustZone devices. The shortcoming is it doesn’t cover MPC/PPC configuration, yet. Ideally we can enhance CMSIS standard to offer a “TrustZone_Setup()” function (the name is still to be defined) that does all this. That would simplify the TF-M HAL to just one single function call that should be provided by each TrustZone-Device low level init code. The final question is: When does this function need to be called? Are you aware of any reason why we should not configure the “system isolation” already during low level init (pre-main)? This could simplify TF-M code even more. In TF-M we could simply rely on a properly configured TrustZone isolation before running any TF-M code. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] Arm Germany GmbH Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19 Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309 Geschäftsführer: Joachim Krech, Reinhard Keil IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 9 months

1
0
0 0

Re: [TF-M] TrustZone initialisation procedure

by Abhishek Pandit

Hi, I see this slight differently. The purpose of TF-M HAL is to abstract out specific HW dependencies from the SW framework for creating isolated secure partitions. As you can understand, various systems have differences in what components are utilized for isolation, but TF-M needs to implement a generic mechanism that works across multiple platforms. Therefore it's important to consider what's platform specific and what's generic. In that sense, SAU and other system components are specific to the underlying HW hence should be part of platform implementation. Of course, it is possible to implement a unified HAL for a family of devices, however I would still expect the hardware abstraction layer in TF-M to remain agnostic of how the HW implements/facilitates isolation of secure world. I don't disagree with the suggestion about enhancements but they seem platform specific to me so should be discussed in that context. Thanks, Abhishek From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 04 March 2020 03:14 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TrustZone initialisation procedure Hi Jonatan, The enhancement of this TZ_SAU_Setup() sounds reasonable, and there are more background items to be considerate: * The SPM need to re-configure the isolation hardware dynamically under isolation level 3 while SPM scheduling, and MPC/PPC is potentially included. So I am not sure what the 'system isolation' mean in your mail, if you want a static initialization for all isolation settings then it will not work for SPM at least for the isolation level 3 design. If it includes the minimal security (and fundamental) setting while system booting and there are other functions to update the isolation setting later, it is do-able. * How does the parameter pass into this function? Because SPM needs to know the status of the existing isolation setting for some purposes (such as security checking), so there needs to be a way to let SPM know the isolation status. So if we do the fundamental security setup in SystemInit(), the advantage is the protection is already enabled between SystemInit() exits and SPM_Init() (There are platform init process in this stage). The cons are SPM may not check the isolation status. And if we do isolation in SPM_Init(), the advantage is SPM can know the status and the cons are Platform Init is not restricted (It could access anywhere). I would suggest not to propose the calling time strictly for this new enhanced API. I know cypress uses customized protection initialization mechanism so any ideas? BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jonatan Antoni via TF-M Sent: Tuesday, March 3, 2020 11:09 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] TrustZone initialisation procedure Hi all, I am trying to align TrustZone initialisation procedure between TF-M and CMSIS. In CMSIS the approach from the early v8-M days is to have a "partition.h" file providing "TZ_SAU_Setup()" function. This function is called during low level "SystemInit()" which runs as part of the pre-main (called from ResetHandler and before running C lib init). In contrast TF-M calls "tfm_spm_hal_init_isolation_hw()" (which is similar to "TZ_SAU_Setup()" plus PPC/MPC configuration) during "tfm_core_init()" (which runs in secure "main()"). The advantage of "TZ_SAU_Setup()" is that this function is available by standard for all TrustZone devices. The shortcoming is it doesn't cover MPC/PPC configuration, yet. Ideally we can enhance CMSIS standard to offer a "TrustZone_Setup()" function (the name is still to be defined) that does all this. That would simplify the TF-M HAL to just one single function call that should be provided by each TrustZone-Device low level init code. The final question is: When does this function need to be called? Are you aware of any reason why we should not configure the "system isolation" already during low level init (pre-main)? This could simplify TF-M code even more. In TF-M we could simply rely on a properly configured TrustZone isolation before running any TF-M code. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] Arm Germany GmbH Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19 Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309 Geschäftsführer: Joachim Krech, Reinhard Keil IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 9 months

1
0
0 0

TF-M Profile 1 design document under review

by David Hu

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

1
0
0 0

Re: [TF-M] SPM_IDLE

by Ken Liu

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

1
0
0 0

Recent patches

by Thomas Törnblom

I have just pushed a simple one liner for tools/tfm_parse_manifest_list.py, which keeps the generated #include file names using unix style paths, even if the files were generated on windows. In the past I have manually fixed up the paths on the generated #include lines in some of the files, but got bored and fixed the script instead. https://review.trustedfirmware.org/c/trusted-firmware-m/+/3605 I also pushed a major (80 files) fix last night that cleans up most of the warnings when building with the IAR toolkit, which for now has more warnings enabled than ARMCLANG and GNUARM. This should make it easier to enable "pedantic" mode with GNUARM as well. https://review.trustedfirmware.org/c/trusted-firmware-m/+/3594 Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 9 months

1
0
0 0

Entry to TF-M

by Reinhard Keil

Hi, Today, I measured the call overhead on the function entry to TF-M is significant and will cause side effects for time deterministic MCU applications using the MDK debugger on STM32L5. Compiler: AC6.14 -oz (optimized for image size) TFM configuration: TFM_LVL=1, library mode, TFM_NS_CLIENT_IDENTIFICATION = OFF --- Execution time measurement: Function call of NS psa_open_key to corresponding secure function: NS: dispatch -> S: tfm_crypto_open_key 2135 cycles NS: dispatch -> S: psa_open_key 2536 cycles NS: psa_open_key -> S: psa_open_key 2825 cycles (this is with RTOS mutex overhead) tfm_core_sfn_request(const struct tfm_sfn_req_s *desc_ptr) { __ASM volatile( "PUSH {r4-r12, lr} \n" "SVC %[SVC_REQ] \n" <--- effectively disables interrupts for 1970 Cycles "MOV r4, #0 \n" On Musca (~48MHz) the overhead is 45us for a TF-M call. --- Code Size overhead: Each TFM function has the following flow: tfm_ns_interface_dispatch (this is a central function) #33 result = fn(arg0, arg1, arg2, arg3); -> calls each TF-M function with individual veneer tfm_core_partition_request (which is again central function) As function inlining is used, the each veneer requires 180 bytes. In my system there are 4 ITS and 46 Crypto functions; with the net result of ~10K code for just the veneer entries. Here are some suggestions: * Using a central entry point to TF-M could save ~10KB; I suggest a table driven approach (could be generated from "manifest" information). * In LVL1 isolation, why is it required to switch from NS: thread->S: handler->S: thread mode. Is it not possible to just call NS: thread-> S: thread? * Disabling NS interrupts for 1970 cycles will be problematic for many time critical applications that are ISR driven; some is caused by parameter checking: * current sequence: first check, then copied (which requires to disable interrupts); Better: First copy, then check could avoid ISR blocking. I hope this helps to improve TFM. Reinhard

5 years, 9 months

2
1
0 0

Re: [TF-M] TF-M Technical Forum call - March 5

by Bill Fletcher

Hi Reinhard, On Wed, 4 Mar 2020 at 15:41, Reinhard Keil via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Is there a forum call tomorrow? > Yes there is. At 0700 UTC. > > > Where can I find the dail-in information? > Clicking on the Google calendar image on https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ should take you to the invite. Regards Bill > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 9 months

1
0
0 0

TF-M Technical Forum call - March 5

by Reinhard Keil

Is there a forum call tomorrow? Where can I find the dail-in information?

5 years, 9 months

1
0
0 0

Questions on TFM_NS_CLIENT_IDENTIFICATION

by Reinhard Keil

TFM_NS_CLIENT_IDENTIFICATION seems to be a feature of the v8M implementation only. Is this correct? Is this feature explained somewhere? As it is disabled in the implementation that I'm using, would it be possible to complete the removal of code that implements it? Thanks Reinhard ti

5 years, 9 months

1
0
0 0

SPM_IDLE

by DeMars, Alan

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

1
0
0 0

memcpy variants

by Reinhard Keil

Just some minor observation: There are various variants of memory functions in tfm core * tfm_memory_utils.h defines a set of identical functions * tfm_core_utils.c/h has another set - functional equivalent with the C run-time library Why are these functions duplicated? It would be Ok if they address some additional security concerns (that I currently don't understand). But todays implementation just add complexity. Reinhard

5 years, 9 months

1
0
0 0

TrustZone initialisation procedure

by Reinhard Keil

Hi Ken, Hi Jonatan, Here is how I see it: * PPC, MPC control system wide the access rights; DMA and other bus masters cannot bypass * SAU controls the access rights on the Processing Element * MPU controls the access rights within a execution domain (secure, non-secure) The setup for TF-M should be: * Isolation Level 1: static SAU, PPC, MPC setup * Isolation Level 2: adds static MPU setup (for privilege, non-privilege separation - could be reflected in PPC, MPC when it is supported by the device) * Isolation Level 3: dynamic MPU setup (depending on the service executed) Changing PPC, MPC setup dynamically does not make sense, as in most devices DMA could bypass TF-M. If this schema is acceptable, TF-M could always assume correct setup of Isolation level 1. A static #define could reflect that. If you think it should be different, please explain why a different schema would add further security to the overall system. Reinhard

5 years, 9 months

1
0
0 0

Re: [TF-M] TrustZone initialisation procedure

by Ken Liu

Hi Jonatan, The enhancement of this TZ_SAU_Setup() sounds reasonable, and there are more background items to be considerate: * The SPM need to re-configure the isolation hardware dynamically under isolation level 3 while SPM scheduling, and MPC/PPC is potentially included. So I am not sure what the 'system isolation' mean in your mail, if you want a static initialization for all isolation settings then it will not work for SPM at least for the isolation level 3 design. If it includes the minimal security (and fundamental) setting while system booting and there are other functions to update the isolation setting later, it is do-able. * How does the parameter pass into this function? Because SPM needs to know the status of the existing isolation setting for some purposes (such as security checking), so there needs to be a way to let SPM know the isolation status. So if we do the fundamental security setup in SystemInit(), the advantage is the protection is already enabled between SystemInit() exits and SPM_Init() (There are platform init process in this stage). The cons are SPM may not check the isolation status. And if we do isolation in SPM_Init(), the advantage is SPM can know the status and the cons are Platform Init is not restricted (It could access anywhere). I would suggest not to propose the calling time strictly for this new enhanced API. I know cypress uses customized protection initialization mechanism so any ideas? BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jonatan Antoni via TF-M Sent: Tuesday, March 3, 2020 11:09 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TrustZone initialisation procedure Hi all, I am trying to align TrustZone initialisation procedure between TF-M and CMSIS. In CMSIS the approach from the early v8-M days is to have a "partition.h" file providing "TZ_SAU_Setup()" function. This function is called during low level "SystemInit()" which runs as part of the pre-main (called from ResetHandler and before running C lib init). In contrast TF-M calls "tfm_spm_hal_init_isolation_hw()" (which is similar to "TZ_SAU_Setup()" plus PPC/MPC configuration) during "tfm_core_init()" (which runs in secure "main()"). The advantage of "TZ_SAU_Setup()" is that this function is available by standard for all TrustZone devices. The shortcoming is it doesn't cover MPC/PPC configuration, yet. Ideally we can enhance CMSIS standard to offer a "TrustZone_Setup()" function (the name is still to be defined) that does all this. That would simplify the TF-M HAL to just one single function call that should be provided by each TrustZone-Device low level init code. The final question is: When does this function need to be called? Are you aware of any reason why we should not configure the "system isolation" already during low level init (pre-main)? This could simplify TF-M code even more. In TF-M we could simply rely on a properly configured TrustZone isolation before running any TF-M code. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] Arm Germany GmbH Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19 Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309 Geschäftsführer: Joachim Krech, Reinhard Keil IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 9 months

1
0
0 0

TrustZone initialisation procedure

by Jonatan Antoni

Hi all, I am trying to align TrustZone initialisation procedure between TF-M and CMSIS. In CMSIS the approach from the early v8-M days is to have a "partition.h" file providing "TZ_SAU_Setup()" function. This function is called during low level "SystemInit()" which runs as part of the pre-main (called from ResetHandler and before running C lib init). In contrast TF-M calls "tfm_spm_hal_init_isolation_hw()" (which is similar to "TZ_SAU_Setup()" plus PPC/MPC configuration) during "tfm_core_init()" (which runs in secure "main()"). The advantage of "TZ_SAU_Setup()" is that this function is available by standard for all TrustZone devices. The shortcoming is it doesn't cover MPC/PPC configuration, yet. Ideally we can enhance CMSIS standard to offer a "TrustZone_Setup()" function (the name is still to be defined) that does all this. That would simplify the TF-M HAL to just one single function call that should be provided by each TrustZone-Device low level init code. The final question is: When does this function need to be called? Are you aware of any reason why we should not configure the "system isolation" already during low level init (pre-main)? This could simplify TF-M code even more. In TF-M we could simply rely on a properly configured TrustZone isolation before running any TF-M code. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] Arm Germany GmbH Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19 Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309 Geschäftsführer: Joachim Krech, Reinhard Keil IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 9 months

1
0
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by Andrej Butok

Hi Anton, > I am not sure if TF-M requires add/remove files Not physically, but in scope of a project. This is the fact from very beginning. > With this occasion let me remind that TF-M is an open source project where design proposal or code change are welcome from everyone. Yes, but it should be approved and pushed by leaders, otherwise it will not work, and the main leading force of PSA projects is ARM. After that, the approach should be followed by every committer. Thank you, Andrej From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Tuesday, March 3, 2020 3:24 PM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: Call for a feedback on TF-M adaptation experience Hi Andrej, Thank you for your feedback! I am not sure if TF-M requires add/remove files for config change but have to agree that build system requires review and refactoring to be less restrictive and easy for integration. This is a valuable input for us for improvement planning and task prioritizing. With this occasion let me remind that TF-M is an open source project where design proposal or code change are welcome from everyone. Thanks again, Anton From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 03 March 2020 13:31 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Call for a feedback on TF-M adaptation experience Hi Anton, The biggest inconvenience for us is the way which TFM is using CMAKE. The configuration is done on level of CMAKE - adding/deleting/renaming files based on project-level configuration. So it is difficult to use the original TFM as a component, required for SDKs and CMSIS packs. For every combination of parameters is needed to create a separate project. As it is not possible, we have to choose one typical configuration. For example, if a user need to change from Isolation2&IPC to Isolation1&Lib, it is not enough to change configuration parameters, he/she must manually to add/delete source files in the project. The improvement request: - platform-independent TFM source-code file set must be fixed for any TFM project. - optional functionality must be covered by #ifdef - NOT by adding/deleting files. - allow to change configuration parameters using a user-config file (e.g. as it's done for mbedTLS/Cypto). All these has no conflict with CMAKE and brings no limits to TFM. Please, do not ignore it. Thank you, Andrej Butok 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: Friday, February 7, 2020 2:13 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] Call for a feedback on TF-M adaptation experience Dear All, As I mentioned on yesterday's call, there is a concern on user experience related to TF-M use. To In order to understand and potentially improve it I am looking for a voice of partners who adopted TF-M project. Please share your experience and thoughts on parts which are good or might be done better to simplify TF-M integration with your project. You feedback will be very appreciated in any form - as a response to this mail or as a direct mail to me (anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>) if it's more comfortable for you. Thank you in advance, Anton

5 years, 9 months

1
0
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Soby Mathew

On 02/03/2020 12:00, Andrej Butok via TF-M wrote: > Hi, > > So, I have submitted the mbedCryptoï¿½ issue > https://github.com/ARMmbed/mbed-crypto/issues/380 > > Several missed functions were implemented in the latest mbedCrypto. > Please read the comment. Hi Andrej, I will try to answer some of the questions. TF-M currently uses 3.0.1 tag of mbed-crypto and it has all the functions implemented in that version. We certainly need to be able to migrate to newer versions of mbed-crypto quicker and more easily. This is one of the things I will be looking into as part of the improving the crypto service implementation in TF-M. My current thoughts are that once mbed-crypto implements more of the other PSA crypto APIs, we could sync up TF-M to expose those APIs. > > They also need clarification about the PSA failed test: > > 1)ï¿½psa_asymmetric_encrypt does not have support for ECC keysï¿½ ï¿½ that's > true, the specification currently does not define any algorithm for > psa_asymmetric_encryptï¿½that uses ECC keys. What's the problem there? The PSA-ACK test need to fix this. I will highlight this issue to them. > 2) For the incorrect key derivation error codes, what are the > problematic inputs? There is an issue raised with mbed-crypto team discussing this issue here : https://github.com/ARMmbed/mbed-crypto/issues/175 As I understand, this needs to be fixed by mbed-crypto. > > 3) For ï¿½psa_generate_key generates incorrect key length for RSAï¿½, what > are the problematic inputs? > > Could you clarify or this is the PSA-Test-Suite task? The problematic input can be seen here : https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/dev_ap… This is a mismatch between the test and the crypto implementation. PSA ACK test project had been notified. I will be following up with them. > > BTW: > > 1) ï¿½mbedCrypto does not use the PSA test suite for testing (they have > own tests). Yes, that is true. > > 2) PSA Test Suite does not inform mbedCrypto about found PSA issues. There is some communication as seen by the issues referenced above, but can be better > > 3) TFM updates to the latest mbedCrypto have to be more often (ideally > after each mbedCrypto release). > > 4) Better synchronization between the PSA Projects is needed. > Yes, certainly. Although syncing to every mbed-crypto release is too much of an overhead for TF-M and the current plan is to sync up once mbed-crypto has resolved a sizeable amount of unimplemented APIs. We are open to contributions in this regard. Currently, all of them are moving targets, the PSA ACK tests, TF-M, mbed-crypto and the PSA specification. The mbed-crypto is moving towards PSA 1.0 whereas the PSA-ACK tests are targeting PSA 1.0 Beta3. This creates some of the mismatches. Once the APIs have stabilized, it should be a matter of picking up the latest mbed-crypto tag and everything should work as expected. Best Regards Soby Mathew > Thanks, > > Andrej Butok > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Andrej Butok via TF-M > *Sent:* Friday, February 28, 2020 1:20 PM > *To:* Anton Komlev <Anton.Komlev(a)arm.com> > *Cc:* tf-m(a)lists.trustedfirmware.org > *Subject:* Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed > > Hi Anton, > > OK. So this is the known issue. Is there any plan when it should be > implemented? > > As the test-log is used for a PSA certification, may we disable the > failed tests? > > BTW: As this is known issue, I did not notice it here > https://github.com/ARMmbed/mbed-crypto/issues?page=1&q=is%3Aissue+is%3Aopen… > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> > > Thanks, > > Andrej > > *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:* Friday, February 28, 2020 12:14 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:* Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed > > Hello Andrej, > > As you noted, the main reason of test failures is unimplemented PSA > functions. Those functions are directly dependent on Embed-Crypto > library where they are missed or API is not adjusted. > > Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1 > and will continue so, increasing test suite coverage. > > Best regards, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org > <mailto:tf-m-bounces@lists.trustedfirmware.org>> *On Behalf Of *Andrej > Butok via TF-M > *Sent:* 28 February 2020 09:46 > *To:* tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > *Subject:* [TF-M] PSA-Test Suite, 23 Crypto Tests failed > > Hello, > > After update to the latest TFM and to the latest PSA-Test Suite, 23 > Crypto Tests are failed: > > ************ Crypto Suite Report ********** > > TOTAL TESTSï¿½ï¿½ï¿½ï¿½ : 61 > > TOTAL PASSEDï¿½ï¿½ï¿½ : 37 > > TOTAL SIM ERROR : 0 > > TOTAL FAILEDï¿½ï¿½ï¿½ : 23 > > TOTAL SKIPPEDï¿½ï¿½ : 1 > > ****************************************** > > The main reason is that many of PSA Crypto functions are not implemented > by TFM. > > Is there a plan to fix it? > > Thanks, > > Andrej >

5 years, 9 months

3
2
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by David Hu

Hi Reinhard, Do you mind describing more details about separating single core v8M from dual core v7M? Do you require more documents or some improvement on code? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Monday, March 2, 2020 6:10 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Call for a feedback on TF-M adaptation experience Hi Anton, Hi Kevin, Thanks for starting this discussion. Let me give you my view on it. I think the problem can be structured in these parts: * Give documentation a better overall structure * Clearly separate single core v8M from dual core v7M * Describe the overall structure of the files and configuration options of TF-M * Describe resource requirements of TF-M core * Describe platform interfaces and provide templates * Describe how a Service is added to TF-M * Describe the tools/utilities that are used for TF-M While the debugging aspect raised by Kevin is relevant, it is a generic problem for all v8-M projects, not just for TF-M. I'm supportive to provide tools like pyOCD, but we need proper resourcing for it (maybe a separate project). It should be also noted that the industry works typically with tools like EWARM, MDK, or vendor specific tools like STCube or MCUxpresso. Hence we should not directly add too much tool-specific information to TF-M itself. Now let me give more context to each of the above topics. ---- Give documentation a better overall structure The Trusted Firmware-M documentation starts here: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… While this is already a User's Guide, it contains two more user's guides https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… For an outsider it is unclear where to start. Clearly separate single core v8M from dual core v7M This seems to be somewhat better now as it seems that below only refers to v8M single core: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Describe the overall structure of the files and configuration options of TF-M I was looking for something like this: https://arm-software.github.io/CMSIS_5/RTOS2/html/pDirectory_Files.html https://arm-software.github.io/CMSIS_5/RTOS2/html/config_rtx5.html Describe resource requirements of TF-M core Take a look here to understand that request https://arm-software.github.io/CMSIS_5/RTOS2/html/pHardwareRequirements.html Important is also to document the interrupt behaviour (for both the secure and non-secure side). I know that this is tricky. For RTX we have this here: https://arm-software.github.io/CMSIS_5/RTOS2/html/cre_rtx_proj.html#cre_Usi… For TF-M this depends on a lot of other parameters. Describe platform interfaces and provide templates What I mean by that are the functions itself that are called by TF_M core. This is an example of the OS_Tick interface that RTX is using. TF-M core has similar interfaces to setup MPC, PPC, SAU, etc. https://arm-software.github.io/CMSIS_5/RTOS2/html/group__CMSIS__RTOS__TickA… Describe how a Service is added to TF-M Assume I have functions currently used in NS. What would be the process to move this functions into TF-M as a service. How does the API interface change, what modifications do I need (ideally I would like to have the same API interface after it). Are the any rules for the API interface itself. You could also provide an example for that, i.e. functions that read a PIN number from an secure keypad or open a DOOR depending on a verification. I know making a good product is hard and takes time. CMSIS is not perfect either. Let me know if you have any questions. Reinhard

5 years, 9 months

2
3
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Andrej Butok

Hi, So, I have submitted the mbedCrypto issue https://github.com/ARMmbed/mbed-crypto/issues/380 Several missed functions were implemented in the latest mbedCrypto. Please read the comment. They also need clarification about the PSA failed test: 1)"psa_asymmetric_encrypt does not have support for ECC keys" - that's true, the specification currently does not define any algorithm for psa_asymmetric_encrypt that uses ECC keys. What's the problem there? 2) For the incorrect key derivation error codes, what are the problematic inputs? 3) For "psa_generate_key generates incorrect key length for RSA", what are the problematic inputs? Could you clarify or this is the PSA-Test-Suite task? BTW: 1) mbedCrypto does not use the PSA test suite for testing (they have own tests). 2) PSA Test Suite does not inform mbedCrypto about found PSA issues. 3) TFM updates to the latest mbedCrypto have to be more often (ideally after each mbedCrypto release). 4) Better synchronization between the PSA Projects is needed. Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday, February 28, 2020 1:20 PM To: Anton Komlev <Anton.Komlev(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hi Anton, OK. So this is the known issue. Is there any plan when it should be implemented? As the test-log is used for a PSA certification, may we disable the failed tests? BTW: As this is known issue, I did not notice it here https://github.com/ARMmbed/mbed-crypto/issues?page=1&q=is%3Aissue+is%3Aopen…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> Thanks, Andrej 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: Friday, February 28, 2020 12:14 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: Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hello Andrej, As you noted, the main reason of test failures is unimplemented PSA functions. Those functions are directly dependent on Embed-Crypto library where they are missed or API is not adjusted. Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1 and will continue so, increasing test suite coverage. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 28 February 2020 09:46 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hello, After update to the latest TFM and to the latest PSA-Test Suite, 23 Crypto Tests are failed: ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 37 TOTAL SIM ERROR : 0 TOTAL FAILED : 23 TOTAL SKIPPED : 1 ****************************************** The main reason is that many of PSA Crypto functions are not implemented by TFM. Is there a plan to fix it? Thanks, Andrej

5 years, 9 months

1
0
0 0

Call for a feedback on TF-M adaptation experience

by Reinhard Keil

Hi Anton, Hi Kevin, Thanks for starting this discussion. Let me give you my view on it. I think the problem can be structured in these parts: * Give documentation a better overall structure * Clearly separate single core v8M from dual core v7M * Describe the overall structure of the files and configuration options of TF-M * Describe resource requirements of TF-M core * Describe platform interfaces and provide templates * Describe how a Service is added to TF-M * Describe the tools/utilities that are used for TF-M While the debugging aspect raised by Kevin is relevant, it is a generic problem for all v8-M projects, not just for TF-M. I'm supportive to provide tools like pyOCD, but we need proper resourcing for it (maybe a separate project). It should be also noted that the industry works typically with tools like EWARM, MDK, or vendor specific tools like STCube or MCUxpresso. Hence we should not directly add too much tool-specific information to TF-M itself. Now let me give more context to each of the above topics. ---- Give documentation a better overall structure The Trusted Firmware-M documentation starts here: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… While this is already a User's Guide, it contains two more user's guides https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… For an outsider it is unclear where to start. Clearly separate single core v8M from dual core v7M This seems to be somewhat better now as it seems that below only refers to v8M single core: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Describe the overall structure of the files and configuration options of TF-M I was looking for something like this: https://arm-software.github.io/CMSIS_5/RTOS2/html/pDirectory_Files.html https://arm-software.github.io/CMSIS_5/RTOS2/html/config_rtx5.html Describe resource requirements of TF-M core Take a look here to understand that request https://arm-software.github.io/CMSIS_5/RTOS2/html/pHardwareRequirements.html Important is also to document the interrupt behaviour (for both the secure and non-secure side). I know that this is tricky. For RTX we have this here: https://arm-software.github.io/CMSIS_5/RTOS2/html/cre_rtx_proj.html#cre_Usi… For TF-M this depends on a lot of other parameters. Describe platform interfaces and provide templates What I mean by that are the functions itself that are called by TF_M core. This is an example of the OS_Tick interface that RTX is using. TF-M core has similar interfaces to setup MPC, PPC, SAU, etc. https://arm-software.github.io/CMSIS_5/RTOS2/html/group__CMSIS__RTOS__TickA… Describe how a Service is added to TF-M Assume I have functions currently used in NS. What would be the process to move this functions into TF-M as a service. How does the API interface change, what modifications do I need (ideally I would like to have the same API interface after it). Are the any rules for the API interface itself. You could also provide an example for that, i.e. functions that read a PIN number from an secure keypad or open a DOOR depending on a verification. I know making a good product is hard and takes time. CMSIS is not perfect either. Let me know if you have any questions. Reinhard

5 years, 9 months

1
0
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Andrej Butok

Hi Anton, OK. So this is the known issue. Is there any plan when it should be implemented? As the test-log is used for a PSA certification, may we disable the failed tests? BTW: As this is known issue, I did not notice it here https://github.com/ARMmbed/mbed-crypto/issues?page=1&q=is%3Aissue+is%3Aopen… Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, February 28, 2020 12:14 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hello Andrej, As you noted, the main reason of test failures is unimplemented PSA functions. Those functions are directly dependent on Embed-Crypto library where they are missed or API is not adjusted. Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1 and will continue so, increasing test suite coverage. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 28 February 2020 09:46 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hello, After update to the latest TFM and to the latest PSA-Test Suite, 23 Crypto Tests are failed: ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 37 TOTAL SIM ERROR : 0 TOTAL FAILED : 23 TOTAL SKIPPED : 1 ****************************************** The main reason is that many of PSA Crypto functions are not implemented by TFM. Is there a plan to fix it? Thanks, Andrej

5 years, 9 months

1
0
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Anton Komlev

Hello Andrej, As you noted, the main reason of test failures is unimplemented PSA functions. Those functions are directly dependent on Embed-Crypto library where they are missed or API is not adjusted. Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1 and will continue so, increasing test suite coverage. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 28 February 2020 09:46 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hello, After update to the latest TFM and to the latest PSA-Test Suite, 23 Crypto Tests are failed: ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 37 TOTAL SIM ERROR : 0 TOTAL FAILED : 23 TOTAL SKIPPED : 1 ****************************************** The main reason is that many of PSA Crypto functions are not implemented by TFM. Is there a plan to fix it? Thanks, Andrej

5 years, 9 months

1
0
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by Kevin Townsend

Hi Anton, One particular difficulty I've encountered working with TF-M for the Zephyr certification demo app, and with the LPC55S69 port to upstream TF-M is the debugging experience with GDB and the dual execution environments. GDB can be quite powerful if you are familiar with it, but there is a definite learning curve, and the S and NS separation and the dual binary images (three with BL2) adds an additional degree of complexity. I think having a dedicated debugging tutorial around GDB would be very useful to people adopting TF-M and perhaps new to GDB, just to show how some basic debugging might happen, how to debug across the NS/S boundary, etc. For example, the '--tui' option for GDB may not be very well known, and it may be useful to highlight (see screenshots at the bottom of this issue: https://github.com/microbuilder/trusted-firmware-m/issues/1) Practical, step-by-step debugging documentation just seems like a good investment to help flatten this inevitable learning curve developing real-world solutions with TF-M? Best regards, Kevin On Thu, 27 Feb 2020 at 13:13, Anton Komlev via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > A kind reminder. > Your feedback is valuable all the time with no deadline defined. > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> * On Behalf Of *Anton > Komlev via TF-M > *Sent:* 07 February 2020 13:13 > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* [TF-M] Call for a feedback on TF-M adaptation experience > > > > Dear All, > > > > As I mentioned on yesterday’s call, there is a concern on user experience > related to TF-M use. > > To In order to understand and potentially improve it I am looking for a > voice of partners who adopted TF-M project. > > Please share your experience and thoughts on parts which are good or might > be done better to simplify TF-M integration with your project. > > > > You feedback will be very appreciated in any form – as a response to this > mail or as a direct mail to me (anton.komlev(a)arm.com) if it’s more > comfortable for you. > > > > Thank you in advance, > > Anton > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 9 months

2
1
0 0

PSA-Test Suite, 23 Crypto Tests failed

by Andrej Butok

Hello, After update to the latest TFM and to the latest PSA-Test Suite, 23 Crypto Tests are failed: ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 37 TOTAL SIM ERROR : 0 TOTAL FAILED : 23 TOTAL SKIPPED : 1 ****************************************** The main reason is that many of PSA Crypto functions are not implemented by TFM. Is there a plan to fix it? Thanks, Andrej

5 years, 9 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - March 5

by David Hu

Hi Anton, I'd like to share about the current design and draft implementation of TF-M Profile 1. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, February 25, 2020 1:11 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - March 5 Dear All, The next Technical Forum is planned on Thursday, March 5 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 9 months

1
0
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by Anton Komlev

A kind reminder. Your feedback is valuable all the time with no deadline defined. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 07 February 2020 13:13 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Call for a feedback on TF-M adaptation experience Dear All, As I mentioned on yesterday's call, there is a concern on user experience related to TF-M use. To In order to understand and potentially improve it I am looking for a voice of partners who adopted TF-M project. Please share your experience and thoughts on parts which are good or might be done better to simplify TF-M integration with your project. You feedback will be very appreciated in any form - as a response to this mail or as a direct mail to me (anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>) if it's more comfortable for you. Thank you in advance, Anton

5 years, 9 months

1
0
0 0

Re: [TF-M] Update Crypto, SST and Attestation services to the latest versions

by Soby Mathew

Hi Everyone The below mentioned patches have been merged to TF-M master. The Open CI is also updated to pull in the right version of mbed-crypto (3.0.1) and it should now show results as expected. You may to have rebase your existing patches currently in review if you need to run CI tests. Best Regards Soby Mathew > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby > Mathew via TF-M > Sent: 18 February 2020 11:38 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Update Crypto, SST and Attestation services to the latest > versions > > Hi Everyone, > This is a heads up that there are patches in review which update the Crypto, > SST and Attestation services to latest versions of their respective specifications : > > 1. Crypto-service migration to Mbed Crypto 3.0.1 > > The patches is available here : > https://review.trustedfirmware.org/q/topic:%22crypto_update%22+(status:ope > n%20OR%20status:merged) > > This migrates the crypto service to the latest implementation of PSA > specification as implemented by mbed-crypto. > > 2. SST: Implement PSA Protected Storage 1.0 > > https://review.trustedfirmware.org/q/topic:%22sst-1.0- > update%22+(status:open%20OR%20status:merged) > > 3. Initial Attestation: Align interface to PSA API 1.0 > > https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature- > psa-dev-api-update&id=b8d88ce6fb7c8e7301f32ab7f6b36dd796692f98 > > and > > https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature- > psa-dev-api-update&id=12c02d16958c9dbd57a6bebe6f29b7a207355831 > > These patches are expected to be reviewed and merged back to the master in > the next couple of weeks. > > Best Regards > Soby Mathew > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 9 months

1
0
0 0

TF-M Technical Forum call - March 5

by Anton Komlev

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

5 years, 9 months

1
0
0 0

TF-M

by Konstantinos Chatzis

Hi all, As Anton already announced during last TF-M Tech Forums, we have recently started a deep review initiative for the TF-M project, with main focus to improve User Experience and reduce Onboarding Effort. The team is currently focusing on the following topics: * Repository and Housekeeping * Development Environment * Build System * Source tree structure and Abstraction Layers * Coding Rules * Documentation * Continuous Integration * Testing We are fully aware of the vast area the topics above cover but, focusing on the basic principles mentioned above, we intend to conclude to implementable solutions. It is therefore of significant importance that your individual or team's onboarding experience is shared with us and this mailing list. Please share any feedback based on your experience using and/or enhancing TF-M. Regards, Kostas IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 9 months

1
0
0 0

TF-M (PSA-Level) Fuzzing Tool

by Gary Morrison

Hi TF-Mers! Sincere apologies for the short notice, but at the next TF-M Tech Forum (in a few hours from now!), I will do a short presentation on a TF-M Fuzzing Tool that I’ve been working on for 2-3 months. Currently, it’s just a prototype, and I’ve only tested SST functionality so far, but we’re hoping we can get it out into the open-source arena soon, and get a little more brain power into improving its capabilities. (Apologies also that it’ll be at 1AM my time, out here in Austin, so please bear with me if I sound a little groggy! 😊) Hope you can join us! -- Gary Morrison gary.morrison(a)arm.com Principal SW Engineer Arm, Inc. Austin, TX. USA

5 years, 9 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - February 20

by Minos Galanakis

Hello all, I will be presenting about the use of "SFN" section for handling object placement in the Secure Side and how this may hide dragons. Regards, Minos Galanakis ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 11 February 2020 12:04 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - February 20 Dear All, The next Open Technical Forum is planned on Thursday, February 20 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 9 months

1
0
0 0

Update Crypto, SST and Attestation services to the latest versions

by Soby Mathew

Hi Everyone, This is a heads up that there are patches in review which update the Crypto, SST and Attestation services to latest versions of their respective specifications : 1. Crypto-service migration to Mbed Crypto 3.0.1 The patches is available here : https://review.trustedfirmware.org/q/topic:%22crypto_update%22+(status:open… This migrates the crypto service to the latest implementation of PSA specification as implemented by mbed-crypto. 2. SST: Implement PSA Protected Storage 1.0 https://review.trustedfirmware.org/q/topic:%22sst-1.0-update%22+(status:ope… 3. Initial Attestation: Align interface to PSA API 1.0 https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature-ps… and https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature-ps… These patches are expected to be reviewed and merged back to the master in the next couple of weeks. Best Regards Soby Mathew

5 years, 10 months

1
0
0 0

Call for review of dual-cpu test cases patches

by David Hu

Hi all, Thanks a lot for the reviews and support for dual-cpu multiple NS PSA client calls feature in TF-M. The patches were merged. Another patch set, which adds test cases for dual-cpu multiple NS PSA client calls, have also been reviewed several rounds in last 2 months, together with feature patches. I’d like to merge the test case patches *by this Thursday* if no further comment. Please help review https://review.trustedfirmware.org/q/topic:%22dualcpu-test-framework%22+(st… if you have interest. 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: Wednesday, February 12, 2020 9:47 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Dual-cpu multiple NS PSA client calls feature Hi all, I’d like to submit the patches to enable multiple NS PSA client calls feature on dual-cpu system *by this week*, if no more comments. The patches have been reviewed for several rounds in last two months. Thanks a lot for all your reviews, comments and validation. The patch set can support NS side to start multiple outstanding PSA client calls concurrently, on dual-cpu system. The feature is enabled and verified on Cypress PSoC 64 platform. If you are interested, please take a look at https://review.trustedfirmware.org/q/topic:%22dualcpu-multi-client-call%22+…. The overall design is discussed in design documents https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… and https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… Comments and suggestions are still and always welcome. 😊 Thank you. Best regards, Hu Ziji

5 years, 10 months

1
0
0 0

[RFC] Update on SPRTL design document

by Ken Liu

Hi, There is something out of fashion in the first version SPRTL document, and the content is not well-formatted in a not ideal place. I updated parts of the document: - Re-format the document. - Fixes the descriptions for C runtime API, now we are re-using the headers, types and parts of toolchain library if possible. - Important change: Define a new 'SP Scratch' area and needs SPM cooperation to let the SPRTL can retrieve SP specific metadata. The new SP scratch area is used for resolving the context-based runtime API cannot retrieve the SP metadata problem since SPRTL is just a code. With this change, the SPRTL has a way to retrieve the SP metadata and then context-based runtime API is much easier in implementation. The patch is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3457 And the issue: https://developer.trustedfirmware.org/T484 Thanks. /Ken

5 years, 10 months

1
0
0 0

Invitation: TF-M Tech Forum @ Every 2 weeks from 07:00 to 08:00 on Thursday from Thu 20 Feb to Fri 27 Mar (GMT) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h When: Every 2 weeks from 07:00 to 08:00 on Thursday from Thu 20 Feb to Fri 27 Mar 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=MnZtamowZG5xZXQzNDdrZ… 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] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode"

by Andrej Butok

Hi Ken, Yes, we are using L2. I have just switched to the latest commit which includes the suggested fix. But tfm_nspm_thread_entry() still goes to the MemManage_Handler() fault a bit later on "push {r0, r1} \n" Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, January 21, 2020 6:05 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hi Andrej, I guess you are using the level2 configuration. This fault was caused by tfm_nspm_thread_entry is trying to call a function in the privileged area. This commit 'cba90782908626f955fe361f803558181a85c6fc' fixes this problem. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, January 21, 2020 12:14 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hello, Just want to check if this is a known issue. During synchronization to the latest TFM, TFM applications are stuck in the exception handler tfm_nspm_thread_entry ()=>MemManage_Handler(). This issue has been caused by commits (3.1.2020): 1. Revision: 5248af2d7b86775364a0e131eb80ac0330bc81fb Message: Core: Use naked function for ns jumping 1. Revision: 490281df3736b11b62e25bc98d3e2c6e4e10478c Message: Core: Initialize IPC SPM in handler mode The previous commit is fully OK (committed 2.1.2020): Revision: 93dabfd3a35faf9ed88285e09997491e93cefa5c Message: Core: Trigger a system reset for programmer error The commits do not have any changes in the linker files and no changes in target files, only the common and ARMv8 code. It's good to know if this is something known or met before. Thank you, Andrej

5 years, 10 months

2
2
0 0

Dual-cpu multiple NS PSA client calls feature

by David Hu

Hi all, I’d like to submit the patches to enable multiple NS PSA client calls feature on dual-cpu system *by this week*, if no more comments. The patches have been reviewed for several rounds in last two months. Thanks a lot for all your reviews, comments and validation. The patch set can support NS side to start multiple outstanding PSA client calls concurrently, on dual-cpu system. The feature is enabled and verified on Cypress PSoC 64 platform. If you are interested, please take a look at https://review.trustedfirmware.org/q/topic:%22dualcpu-multi-client-call%22+…. The overall design is discussed in design documents https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… and https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… Comments and suggestions are still and always welcome. 😊 Thank you. Best regards, Hu Ziji

5 years, 10 months

1
0
0 0

Re: [TF-M] mbed-crypto version

by Andrej Butok

You may ping here: https://developer.trustedfirmware.org/T561 From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Tuesday, February 11, 2020 1:23 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] mbed-crypto version Are there any plans to upgrade from mbed-crypto-1.1.0 to the latest? There are some IAR specifics I would like to update in CMakeLists.txt for mbed-crypto, but as the version required by tf-m is very old, I don't see that it would help if I update the current version. 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<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iar.co…> Twitter: www.twitter.com/iarsystems<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitte…>

5 years, 10 months

1
0
0 0

mbed-crypto version

by Thomas Törnblom

Are there any plans to upgrade from mbed-crypto-1.1.0 to the latest? There are some IAR specifics I would like to update in CMakeLists.txt for mbed-crypto, but as the version required by tf-m is very old, I don't see that it would help if I update the current version. 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

TF-M Technical Forum call - February 20

by Anton Komlev

Dear All, The next Open Technical Forum is planned on Thursday, February 20 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] Test: Update test framework API

by Jamie Fox

Hi Devaraj, Happy to merge it for you, but first please can you add a comment to the gerrit review with details of testing done for the patch? Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: 10 February 2020 09:50 To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] Test: Update test framework API Hi TF-M maintainers, It looks like there is no objection to the patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172. Can you please merge it? Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Devaraj Ranganna via TF-M <TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>> Reply to: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com<mailto:Devaraj.Ranganna@arm.com>> Date: Tuesday, 4 February 2020 at 16:30 To: "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: [TF-M] Test: Update test framework API Hi, Currently the test framework which executes test suites doesn't return anything. Therefore it is not possible for application layer to know the status of test cases. The patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172 is intended to export the test case pass/fail status to application layer and beyond (if any test framework is used by Non-secure side). If there are no objections then can the 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. 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] Changes to OS wrapper

by Kevin Peng

Hi Vikas, I'm seeing two topics here if I understand correctly. The first one is how to deal with memory management in the os wrapper implementation. The second one is how to safely "exit" and "delete" a child thread. Please first check if my understanding is correct. For the first topic, except the handles of threads, semaphores or mutex (which are the OS handles I guess), the OS wrapper needs some extra handles for resource handling. For example the pointer of the memory allocated in the OS wrapper API. The two handles forms the new OS wrapper handle you proposed. For the second topic, can we just terminate or delete the child thread by itself after it has done its job? Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: Friday, February 7, 2020 12:55 AM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Jamie Fox <Jamie.Fox(a)arm.com>; Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hi all, Thanks for the e-mail. I would like to highlight a few issues with the current API implementation. * It isn't good for OS which relies on manual memory management, the current API doesn't give an opportunity to free any resources which were in use. * The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources to be freed which are not managed by the OS. So a change in the API implementation is required to address the above issues. * Use `os_wrapper_current_thread_suspend()` and `os_wrapper_thread_terminate(handle)` API, ensuring we suspend and terminate safely, enabling it to free allocated resources. * Remove `os_wrapper_get_handle()` to make sure we differentiate between OS wrapper handle and OS handle. The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle because implementations can't always create an OS-wrapper handle from an OS handle. Comments towards the arguments: * If we go with `os_wrapper_thread_exit()` to exit a child, then OS can allocate that resource to another purpose instantly and if we were to pass that handle to `os_wrapper_thread_delete(handle)`, we still risk corruption. * If we go with `os_wrapper_thread_exit()` suspending the thread Or `os_wrapper_thread_delete(handle)` performing a NOP, it changes the semantics of what API intends to do and is not a natural way of moving forward. Also, it may confuse developers by making exit suspend instead of exit, or delete not delete anything. * If we go with `os_wrapper_thread_exit()` performing a NOP and `os_wrapper_thread_delete(handle)` performing a termination of the thread, there are few things to consider here: * It changes the semantics again for exit, but on some OS if the thread has finished its operations it will either exit or suspend itself as there is nothing to execute further. * If the thread exits then os_wrapper_thread_delete(handle) will result in error. * If we add a wrapper variable that captures info on if the thread has been exited to check deletion is safe or not, there few things to consider here: * Adds an additional maintainability burden. * Tracking if a thread has been exited or not adds a cost in RAM that would not be needed if the API had a good shape. Seeing as we all develop for embedded devices here, we should be very careful with RAM use. * It can't figure out its identification because the OS-wrapper handle is not passed in `os_wrapper_thread_exit()`. Differentiating between the right handle is required to ensure we track the right thread information. Depreciating the old API will ensure the following: * Future applications are portable to any OS that needs manual memory management. * It forces out-of-tree applications using the wrappers to know they need to make a change in order to be portable to operating systems that require manual memory management. * The in-tree applications will be refactored as part of this API change. Further, if there is a matter of handling deprecation of API, then I would like to know how that can be achieved in TF-M? Thanks & Best Regards, Vikas Katariya 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, February 6, 2020 12:16 To: 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] Changes to OS wrapper Hello, Agree with Jamie seeing not enough arguments for extension of existing API. Looks like the required functionality can be hidden inside a specific os_wrapper, which is a main purpose of it. @Vikas, could you explain a bit differently why you are blocked with the current API? Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 06 February 2020 09:10 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@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] Changes to OS wrapper Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@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] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@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: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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. 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
3
0 0

Re: [TF-M] Test: Update test framework API

by Devaraj Ranganna

Hi TF-M maintainers, It looks like there is no objection to the patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172. Can you please merge it? Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Devaraj Ranganna via TF-M <TF-M(a)lists.trustedfirmware.org> Reply to: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Date: Tuesday, 4 February 2020 at 16:30 To: "TF-M(a)lists.trustedfirmware.org" <TF-M(a)lists.trustedfirmware.org> Subject: [TF-M] Test: Update test framework API Hi, Currently the test framework which executes test suites doesn't return anything. Therefore it is not possible for application layer to know the status of test cases. The patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172 is intended to export the test case pass/fail status to application layer and beyond (if any test framework is used by Non-secure side). If there are no objections then can the 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

1
0
0 0

Re: [TF-M] Linking issues with SFN section

by Ken Liu

Hi, Now we just put code and RODATA into SFN so it works. And your concern really exists - for example, if a string is applied during SFN function, the string is actually out of SFN range and we need to put this string variable into SFN, too. The SFN area should be simplified later one and SFN section should be removed (apply specific section to symbol should be restricted, only some special purposes like init-table usage are allowed). Instead, an overall library should be put in TFM_UNPRIV_CODE and with this: ?.lib (+RO) should work for your case - does IAR support this scenario with some a.lib (+RO) or it supports .o files only? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Friday, February 7, 2020 7:11 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Linking issues with SFN section I would like to discuss the use of the SFN section for the secure image. During my port of tf-m to the IAR toolchain I ran into issues related to the SFN section. There are quite a few functions that are placed in the SFN section, which is then linked into the TFM_UNPRIV_CODE block. I don't know how armclang or gcc handles this, but the IAR compiler may generate .rodata initializers, which does not end up in the SFN section, predominantly the in_vec and out_vec structs with debug builds. I've had to manually add the .rodata sections from these object files (tfm_*_secure_api.o) to the TFM_UNPRIV_CODE in the tfm_common linker script in order to work around MemManage_Handler traps. I would like to suggest that the relevant files are added to the relevantï¿½ block in the tfm_common.* linker script instead of using the SFN section. That way one can specify that both the .text (ro code) and .rodata (const) goes into the same block. Comments? 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] Possible race condition in IRQ_TEST_SCENARIO_4?

by Thomas Törnblom

Turns out the issue was with the timer interrupt routine clobbering a register when compiled with no optimization. I have a workaround, but I’m also working with the compiler developers on what the proper behavior is. Thomas Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1<x-apple-data-detectors://6/1> SE-750 23 Uppsala, SWEDEN<x-apple-data-detectors://6/1> Mobile: +46 76 180 17 80<tel:+46%2076%20180%2017%2080> Fax: +46 18 16 78 01<tel:+46%2018%2016%2078%2001> 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> 6 feb. 2020 kl. 09:56 skrev Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>: How is the IRQ_TEST_SCENARIO_4 supposed to work? I suspect that there might be a lurking race condition somewhere in that test. Some, not all, of the (M33/M23) targets gets stuck in that test when the ConfigRegression.cmake config is built with IAR in Debug mode. If I build it with RelWithDebInfo then the test runs OK for all applicable targets. No problems with Debug builds for the other configurations. Occasionally the test will run successfully also for a normally problematic target if I run it in the debugger and stop execution at breakpoints, but it is very random, which is why I suspect there might be a race problem. 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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 10 months

1
0
0 0

Call for a feedback on TF-M adaptation experience

by Anton Komlev

Dear All, As I mentioned on yesterday's call, there is a concern on user experience related to TF-M use. To In order to understand and potentially improve it I am looking for a voice of partners who adopted TF-M project. Please share your experience and thoughts on parts which are good or might be done better to simplify TF-M integration with your project. You feedback will be very appreciated in any form - as a response to this mail or as a direct mail to me (anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>) if it's more comfortable for you. Thank you in advance, Anton

5 years, 10 months

1
0
0 0

Re: [TF-M] Changes to OS wrapper

by Vikas Katariya

Hi all, Thanks for the e-mail. I would like to highlight a few issues with the current API implementation. * It isn't good for OS which relies on manual memory management, the current API doesn't give an opportunity to free any resources which were in use. * The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources to be freed which are not managed by the OS. So a change in the API implementation is required to address the above issues. * Use `os_wrapper_current_thread_suspend()` and `os_wrapper_thread_terminate(handle)` API, ensuring we suspend and terminate safely, enabling it to free allocated resources. * Remove `os_wrapper_get_handle()` to make sure we differentiate between OS wrapper handle and OS handle. The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle because implementations can't always create an OS-wrapper handle from an OS handle. Comments towards the arguments: * If we go with `os_wrapper_thread_exit()` to exit a child, then OS can allocate that resource to another purpose instantly and if we were to pass that handle to `os_wrapper_thread_delete(handle)`, we still risk corruption. * If we go with `os_wrapper_thread_exit()` suspending the thread Or `os_wrapper_thread_delete(handle)` performing a NOP, it changes the semantics of what API intends to do and is not a natural way of moving forward. Also, it may confuse developers by making exit suspend instead of exit, or delete not delete anything. * If we go with `os_wrapper_thread_exit()` performing a NOP and `os_wrapper_thread_delete(handle)` performing a termination of the thread, there are few things to consider here: * It changes the semantics again for exit, but on some OS if the thread has finished its operations it will either exit or suspend itself as there is nothing to execute further. * If the thread exits then os_wrapper_thread_delete(handle) will result in error. * If we add a wrapper variable that captures info on if the thread has been exited to check deletion is safe or not, there few things to consider here: * Adds an additional maintainability burden. * Tracking if a thread has been exited or not adds a cost in RAM that would not be needed if the API had a good shape. Seeing as we all develop for embedded devices here, we should be very careful with RAM use. * It can't figure out its identification because the OS-wrapper handle is not passed in `os_wrapper_thread_exit()`. Differentiating between the right handle is required to ensure we track the right thread information. Depreciating the old API will ensure the following: * Future applications are portable to any OS that needs manual memory management. * It forces out-of-tree applications using the wrappers to know they need to make a change in order to be portable to operating systems that require manual memory management. * The in-tree applications will be refactored as part of this API change. Further, if there is a matter of handling deprecation of API, then I would like to know how that can be achieved in TF-M? Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, February 6, 2020 12:16 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hello, Agree with Jamie seeing not enough arguments for extension of existing API. Looks like the required functionality can be hidden inside a specific os_wrapper, which is a main purpose of it. @Vikas, could you explain a bit differently why you are blocked with the current API? Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 06 February 2020 09:10 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@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] Changes to OS wrapper Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@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] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@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: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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. 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
1
0 0

Linking issues with SFN section

by Thomas Törnblom

I would like to discuss the use of the SFN section for the secure image. During my port of tf-m to the IAR toolchain I ran into issues related to the SFN section. There are quite a few functions that are placed in the SFN section, which is then linked into the TFM_UNPRIV_CODE block. I don't know how armclang or gcc handles this, but the IAR compiler may generate .rodata initializers, which does not end up in the SFN section, predominantly the in_vec and out_vec structs with debug builds. I've had to manually add the .rodata sections from these object files (tfm_*_secure_api.o) to the TFM_UNPRIV_CODE in the tfm_common linker script in order to work around MemManage_Handler traps. I would like to suggest that the relevant files are added to the relevant block in the tfm_common.* linker script instead of using the SFN section. That way one can specify that both the .text (ro code) and .rodata (const) goes into the same block. Comments? 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] PsoC64 build broken

by Christopher Brand

So the patch does the wrong thing anyway - it effectively changes the watermark assertion so that it won't trigger if the TFM_RAM_CODE area goes beyond the end of RAM. That's just broken, because TFM_RAM_CODE is, obviously, supposed to be in RAM. There may well be a problem here, but this is not the correct fix for it. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Thursday, February 6, 2020 3:58 PM To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com>; nd <nd(a)arm.com> Subject: Re: [TF-M] PsoC64 build broken 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. I did an armclang build of the head of master and with this patch reverted, and there is a small difference between them - the TFM_RAM_CODE and SRAM_WATERMARK sections are swapped. That feels wrong, because the TFM_RAM_CODE is inside SRAM, so I'd expect the "end of SRAM watermark" to be after it, not before it. I'm not sure exactly how the watermark section is used, though. On the plus side, TFM_RAM_CODE does indeed still end up at the correct address, in SRAM. I'm not sure exactly which sections you want me to try changing to set the LMA. The line numbers don't seem to match up... Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: Thursday, February 6, 2020 3:43 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] PsoC64 build broken 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. I'd really prefer to see the patch reverted first, and then we can figure out exactly what's going on and push a revised patch that achieves the objectives without breaking anything. It does seem to have some side-effects on the PSoC64 armclang build, too. It's pretty standard open source process to revert a patch that breaks something like this... Chris From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Thursday, February 6, 2020 3:15 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: PsoC64 build broken Hi Chris, Sorry about that. It shouldn't have changed the address of the region though because it's explicitly set to S_RAM_CODE_START. I think this could be down to an "interesting" behaviour in GCC linker scripts where if the LMA is explicitly set with for a region with "AT>", then it won't revert back to being equal to the VMA for the next region in some cases. So before we revert the change, please can you try setting the LMA explicitly for the following region(s)? That is, try "> FLASH AT> FLASH" instead of just "> FLASH" on lines 527 and 563. Best wishes, Jamie ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 06 February 2020 20:11 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>> Subject: [TF-M] PsoC64 build broken Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 ("Build: Fix SRAM sanity check in common scatter file") seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I'm quite surprised that the comments on the review note that "I noticed that this define is currently only used for PSOC6 platform which I don't possess" and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven't dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? Chris 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. 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.

5 years, 10 months

3
2
0 0

Re: [TF-M] PsoC64 build broken

by Christopher Brand

I did an armclang build of the head of master and with this patch reverted, and there is a small difference between them - the TFM_RAM_CODE and SRAM_WATERMARK sections are swapped. That feels wrong, because the TFM_RAM_CODE is inside SRAM, so I'd expect the "end of SRAM watermark" to be after it, not before it. I'm not sure exactly how the watermark section is used, though. On the plus side, TFM_RAM_CODE does indeed still end up at the correct address, in SRAM. I'm not sure exactly which sections you want me to try changing to set the LMA. The line numbers don't seem to match up... Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Thursday, February 6, 2020 3:43 PM To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com>; nd <nd(a)arm.com> Subject: Re: [TF-M] PsoC64 build broken 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. I'd really prefer to see the patch reverted first, and then we can figure out exactly what's going on and push a revised patch that achieves the objectives without breaking anything. It does seem to have some side-effects on the PSoC64 armclang build, too. It's pretty standard open source process to revert a patch that breaks something like this... Chris From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Thursday, February 6, 2020 3:15 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: PsoC64 build broken Hi Chris, Sorry about that. It shouldn't have changed the address of the region though because it's explicitly set to S_RAM_CODE_START. I think this could be down to an "interesting" behaviour in GCC linker scripts where if the LMA is explicitly set with for a region with "AT>", then it won't revert back to being equal to the VMA for the next region in some cases. So before we revert the change, please can you try setting the LMA explicitly for the following region(s)? That is, try "> FLASH AT> FLASH" instead of just "> FLASH" on lines 527 and 563. Best wishes, Jamie ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 06 February 2020 20:11 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>> Subject: [TF-M] PsoC64 build broken Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 ("Build: Fix SRAM sanity check in common scatter file") seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I'm quite surprised that the comments on the review note that "I noticed that this define is currently only used for PSOC6 platform which I don't possess" and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven't dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? Chris 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. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 10 months

1
0
0 0

Re: [TF-M] PsoC64 build broken

by Jamie Fox

Hi Chris, Sorry about that. It shouldn't have changed the address of the region though because it's explicitly set to S_RAM_CODE_START. I think this could be down to an "interesting" behaviour in GCC linker scripts where if the LMA is explicitly set with for a region with "AT>", then it won't revert back to being equal to the VMA for the next region in some cases. So before we revert the change, please can you try setting the LMA explicitly for the following region(s)? That is, try "> FLASH AT> FLASH" instead of just "> FLASH" on lines 527 and 563. Best wishes, Jamie ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 06 February 2020 20:11 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com> Subject: [TF-M] PsoC64 build broken Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 (“Build: Fix SRAM sanity check in common scatter file”) seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I’m quite surprised that the comments on the review note that “I noticed that this define is currently only used for PSOC6 platform which I don't possess” and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven’t dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 10 months

2
1
0 0

PsoC64 build broken

by Christopher Brand

Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 ("Build: Fix SRAM sanity check in common scatter file") seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I'm quite surprised that the comments on the review note that "I noticed that this define is currently only used for PSOC6 platform which I don't possess" and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven't dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 10 months

1
0
0 0

Re: [TF-M] TF-M NS regression tests - linker issue

by Devaraj Ranganna

Hi Ken, I’d prefer that TF-M keep exporting the pre-compiled archive for regression tests. The rational behind that is less files to be added/maintained by NS RTOS. Considering this, I think quick and easy way to solve this is for NS RTOS to implement ` tfm_log_printf ` using the print method available. This way no changes are needed in TF-M. I thought about platform-specific shim layer, like adding a new print function “ns_log_printf” to the OS wrapper (app/os_wrapper_cmsis_rtos_v2.c) and use that for NS regression tests. I believe it’s not worth the effort and also it will add another layer of indirection. To summarise, we’ll implement `tfm_log_printf ` in Mbed OS which should resolve the linker issue. Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Reply to: Ken Liu <Ken.Liu(a)arm.com> Date: Wednesday, 5 February 2020 at 04:50 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue Hi Devaraj, Thanks for the clarification. Looks like this issue is caused by the way the building system integrates the test package with NS RTOS - if source-level integration is applied then the modification is not a problem and this should be the better way - even if we recover the 'printf' implementation, for those RTOS who has no printf, it would be another issue. I think the possible solutions can be: * If we keep using the pre-compiled archive, then some platform-specific shim layer needs to be available to provide platform-specific functions. * If we changed to source-level integration then things would be easier. * A quick way is as you requested, recover back to 'printf'. For the 3rd point, there are some pre-actions to be done: * Make sure the compiler optimization function is limited for easier the implementation of these stdio functions. There is a leading patch for this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3217 * Define the HAL functions for output so that the printf implementation is not CMSIS specific. May I ask how you fix this issue? /Ken ________________________________ From: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Sent: Tuesday, February 4, 2020 11:16 PM To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue Hi Ken, Currently, TF-M build process creates an pre-compiled archive of NS tests and exports it. But the implementation of `tfm_log_printf` is not exported. This causes a linker issue when NS tests archive is linked with NS RTOS, which is the reason why subject of this mail contains `linker issue`. Having said that, exporting `tfm_log_printf` won’t solve the problem because `tfm_log_printf` assumes availability of CMSIS driver framework. Also the latest suggestion on the ticket https://developer.trustedfirmware.org/T664 `And I think if you forward the TEST_LOG to your OS printf implementation then everything would be fine?` won’t help because of pre-compiled archive. It looks like only possible solution for NS RTOS is to implement ` tfm_log_printf `. Please do recommend if you have any other ideas. Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Reply to: Ken Liu <Ken.Liu(a)arm.com> Date: Saturday, 1 February 2020 at 04:46 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue Hi, Why the title is ‘linker issue’ since it is discussing about the printf things? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday, January 31, 2020 9:57 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TF-M NS regression tests - linker issue Hi, The TF-M NS regression tests were portable enough to run in a rich OS environment. After replacing printf with tfm_log_printf, the TF-M regression tests are now no longer portable enough to run in an OS environment. Many OSes already have a way to print, usually via a printf function, and the TF-M regression tests probably should use this. It's important that TF-M regression tests remain portable and capable of running in an OS environment so that system integrators can be confident that TF-M is working as intended post-integration. I’ve already created a ticket for this https://developer.trustedfirmware.org/T664 Response from Ken in the ticket: Hi Jamie, The background for this changing is, the ARMCLANG printf involves \_\_stdout' into the image and this conflicts with some CMSIS functionalities. (CMSIS team reported that __stdout would affect the mutex init in ARMCLANG). That is the reason why I skipped the default printf. I think for an RTOS, the toolchain provided printf sometimes come with unknown symbols and causes unexpected behaviour, as the discussion in list/channel, most people are trying to avoid toolchain printf and use some lightweight output. And for the test, it should use wrapped TEST_LOG(), instead of calling printf itself, since some RTOS do not provide a std 'printf' function. Is there any discussion thread about this issue? Thanks 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, 10 months

2
1
0 0

Re: [TF-M] PSA Test Suite - Attestation test

by Andrej Butok

Hi Tamas > Could you tell what was the values of these compile time switches in your test? For the previous TFM, we have used INCLUDE_TEST_CODE_AND_KEY_ID. For the current TFM it was renamed to INCLUDE_TEST_CODE. Other parameters are new, so I have tried different combinations of these parameters, but the PSA Test-Suite Attestation is still failed. > Further do you implemented the boot data sharing between bootloader and runtime firmware? It's used the TFM template code without change from tfm\platform\ext\common\template > Do you sign SPE and NPSE images together or they are signed separately? We do not use the secondary bootloader so far, so image is not signed. As the Attestation Regression tests are passed. It's good to know what combination of parameters have to be used to generate the same token as it was generated by the older TFM and accepted by the PSA Test Suite (last commit on master branch). Or the PSA Test Suite is obsolete. Thank you, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Wednesday, February 5, 2020 1:13 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Test Suite - Attestation test Hi Andrej, Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 04 February 2020 17:33 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA Test Suite - Attestation test Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok 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
1
0 0

Re: [TF-M] Changes to OS wrapper

by Anton Komlev

Hello, Agree with Jamie seeing not enough arguments for extension of existing API. Looks like the required functionality can be hidden inside a specific os_wrapper, which is a main purpose of it. @Vikas, could you explain a bit differently why you are blocked with the current API? Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 06 February 2020 09:10 To: Vikas Katariya <Vikas.Katariya(a)arm.com>; Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@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] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@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: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

1
0
0 0

Re: [TF-M] Persistent keys in the Crypto service

by Kevin Townsend

Hi Jamie, This aligns well with a key requirement we identified thinking about late binding devices that make use of TF-M, such as with cloud services or providers which tend to use X.509 certificate chains which will need to be signed, and a private key generated and held in secure storage as part of the binding and certification signing process. Some initial thoughts are visible here in interim if it's useful to see a use case for this work: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md Best regards, Kevin On Tue, 4 Feb 2020 at 14:32, Jamie Fox via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi all, > > > > I have pushed for review patches to enable persistent keys in the TF-M > Crypto service. With these changes, persistent keys will be stored by Mbed > Crypto using the ITS APIs exposed by TF-M. > > > > The reviews are here: > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252 > (implementation) > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/3253 (tests) > > > > Currently, merging of these patches is blocked as they depend on Mbed > Crypto 2.0 (or greater), which adds support for the latest ITS 1.0.0 APIs > exposed by TF-M. Integrating Mbed Crypto 2.0 with TF-M is a work in > progress. > > > > If anyone wants to test these patches in the meantime, it is possible to > cherry pick the patch in the Mbed Crypto repo that adds support for ITS > 1.0.0. With the Mbed Crypto repo checked-out at the “mbedcrypto-1.1.0” tag, > do a “git cherry-pick bda5a2111” to cherry pick the relevant patch. > > > > Kind regards, > > Jamie > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 10 months

1
0
0 0

Re: [TF-M] Possible race condition in IRQ_TEST_SCENARIO_4?

by Mate Toth-Pal

Hi Thomas, A brief description of this test scenario is in docs\user_guides\services\core_test_services_integration_guide.rst: <quote> - S code waits for an interrupt (calling ``psa_wait()``), the handler is in the service that is waiting, ``psa_eoi()`` is called after ``psa_wait()`` returns (``IRQ_TEST_SCENARIO_4``) <end quote> ConfigRegression.cmake is using the library model, so that implementation needs to be considered. In this scenario only a secure interrupt is involved. The sequence is the following (only relevant code parts are mentioned): 1. spm_irq_test_1_prepare_test_scenario_internal() starts the secure timer. 2. spm_irq_test_1_execute_test_scenario() enters a while loop, waiting the signal for the timer to be set call psa_wait(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ, PSA_BLOCK); 3. at some point the interrupt is triggered, and the signal is set for the interrupt. The interrupt handler is run, and it sets a flag timer0_triggered. SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ_isr() is the interrupt handler function in this case, and this function executes an explicit "DSB" instruction to be sure that the write to the flag is committed. (The flag is declared as volatile) 4. When the function spm_irq_test_1_execute_test_scenario() exits the loop, it calls pas_eoi(), and returns. At the moment I don't see a flaw in this scenario, which of course gives no guarantee that there isn't a flaw in it somewhere. We often test TF-M in FVP, and found that from time to time the FVP runs slower (seems to be executing less cycles per minute) than usual. In this cases IRQ testcases appeared to be hanging, although if we waited for the necessary number of cycles to be executed by the FVP, these tests always passed. Did you have a chance to have a look at it with a debugger? If so, where exactly is the execution stucked? Have the interrupt been triggered as expected? Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Thursday, February 6, 2020 9:56 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Possible race condition in IRQ_TEST_SCENARIO_4? How is the IRQ_TEST_SCENARIO_4 supposed to work? I suspect that there might be a lurking race condition somewhere in that test. Some, not all, of the (M33/M23) targets gets stuck in that test when the ConfigRegression.cmake config is built with IAR in Debug mode. If I build it with RelWithDebInfo then the test runs OK for all applicable targets. No problems with Debug builds for the other configurations. Occasionally the test will run successfully also for a normally problematic target if I run it in the debugger and stop execution at breakpoints, but it is very random, which is why I suspect there might be a race problem. 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] Changes to OS wrapper

by Gyorgy Szing

Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@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: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

1
0
0 0

Possible race condition in IRQ_TEST_SCENARIO_4?

by Thomas Törnblom

How is the IRQ_TEST_SCENARIO_4 supposed to work? I suspect that there might be a lurking race condition somewhere in that test. Some, not all, of the (M33/M23) targets gets stuck in that test when the ConfigRegression.cmake config is built with IAR in Debug mode. If I build it with RelWithDebInfo then the test runs OK for all applicable targets. No problems with Debug builds for the other configurations. Occasionally the test will run successfully also for a normally problematic target if I run it in the debugger and stop execution at breakpoints, but it is very random, which is why I suspect there might be a race problem. 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] Changes to OS wrapper

by Jamie Fox

Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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
1
0 0

Re: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode"

by Ken Liu

I have created the patch for this issue: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3359 The non-secure entry thread re-uses the same context and stack of initial booting thread, while initial booting thread would update the context in stack while SVC to SPM initialization. The context needs to be reset after SPM initialized all threads, and the EXC_RETURN is missed during the reset process. If initial thread is executed with FP active, the EXC_RETURN generated by SVC would be 0xFFFFFFED, and cause extra 0x48 bytes to be popped while exiting from exception which causes the error. This patch resets the EXC_RETURN to 0xFFFFFFFD. Please help to comment, thanks. /Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, January 22, 2020 10:29 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hi Andrej, I double checked in my platforms and looks fine, so you are porting them to your board, right? I have created a task for detailed description, let’s discuss the details there: https://developer.trustedfirmware.org/T652 Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, January 21, 2020 11:19 PM To: Ken Liu <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: RE: Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hi Ken, Yes, we are using L2. I have just switched to the latest commit which includes the suggested fix. But tfm_nspm_thread_entry() still goes to the MemManage_Handler() fault a bit later on "push {r0, r1} \n" Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Tuesday, January 21, 2020 6:05 AM To: 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] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hi Andrej, I guess you are using the level2 configuration. This fault was caused by tfm_nspm_thread_entry is trying to call a function in the privileged area. This commit ‘cba90782908626f955fe361f803558181a85c6fc’ fixes this problem. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, January 21, 2020 12:14 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hello, Just want to check if this is a known issue. During synchronization to the latest TFM, TFM applications are stuck in the exception handler tfm_nspm_thread_entry ()=>MemManage_Handler(). This issue has been caused by commits (3.1.2020): 1. Revision: 5248af2d7b86775364a0e131eb80ac0330bc81fb Message: Core: Use naked function for ns jumping 1. Revision: 490281df3736b11b62e25bc98d3e2c6e4e10478c Message: Core: Initialize IPC SPM in handler mode The previous commit is fully OK (committed 2.1.2020): Revision: 93dabfd3a35faf9ed88285e09997491e93cefa5c Message: Core: Trigger a system reset for programmer error The commits do not have any changes in the linker files and no changes in target files, only the common and ARMv8 code. It’s good to know if this is something known or met before. Thank you, Andrej

5 years, 10 months

1
0
0 0

Re: [TF-M] Topic proposal for upcoming Open Tech Forum: CMSIS-Zone

by Anton Komlev

Hi Jonatan, All, Thanks for proposing the topic inline with the thread on flash_layout.h and region_defs.h configuration header. Let's discuss it tomorrow. All the best, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jonatan Antoni via TF-M Sent: 05 February 2020 14:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Topic proposal for upcoming Open Tech Forum: CMSIS-Zone Hi all, I'd like to propose to give you a short live presentation (10-15 minutes) of CMSIS-Zone [1]. In Arm DSG we are developing and using CMSIS-Zone to gather required memory partitioning data and generate consistent config file (such as partition headers, SAU/MPC/PPC configs, MPU configs, scatter files, etc). Robi made good progress aligning TF-M with Arm's tool ecosystem, such as componentization for shipping CMSIS-Packs. He used CMSIS-Zone to generate the required config files for TF-M. In my presentation I'd like to focus on configuring TF-M for NXP's LPC55 using CMSIS-Zone. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] [1] https://arm-software.github.io/CMSIS_5/Zone/html/index.html Arm Germany GmbH Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19 Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309 Geschäftsführer: Joachim Krech, Reinhard Keil IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

1
0
0 0

Topic proposal for upcoming Open Tech Forum: CMSIS-Zone

by Jonatan Antoni

Hi all, I'd like to propose to give you a short live presentation (10-15 minutes) of CMSIS-Zone [1]. In Arm DSG we are developing and using CMSIS-Zone to gather required memory partitioning data and generate consistent config file (such as partition headers, SAU/MPC/PPC configs, MPU configs, scatter files, etc). Robi made good progress aligning TF-M with Arm's tool ecosystem, such as componentization for shipping CMSIS-Packs. He used CMSIS-Zone to generate the required config files for TF-M. In my presentation I'd like to focus on configuring TF-M for NXP's LPC55 using CMSIS-Zone. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] [1] https://arm-software.github.io/CMSIS_5/Zone/html/index.html Arm Germany GmbH Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19 Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309 Geschäftsführer: Joachim Krech, Reinhard Keil IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

1
0
0 0

Re: [TF-M] PSA Test Suite - Attestation test

by Tamas Ban

Hi Andrej, Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 04 February 2020 17:33 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite - Attestation test Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 6 Feb 2020 17:00 - 18:00 (GMT) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: 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/──… Fletcher is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New York)+16699009128,,5810428000# 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: 581 042 8000Find your local number: https://zoom.us/u/aerUYXPhSL────────── When: Thu 6 Feb 2020 17:00 – 18:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- organiser * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MGxvN2syYWc0ZWV1NXFia… 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] Changes to OS wrapper

by Vikas Katariya

Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M