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