Hi Anton,

 

Yes, it's a good idea to present this proposal on the Tech Forum. But I will not be able to prepare the presentation by tomorrow. So, I would like to do it in two weeks.

 

Regards,

Roman.

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, September 29, 2021 11:40
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Proposal to separate vendor components

 

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe.

 

Hi Roman,

 

Thanks for the interesting proposal. Would you like to present and discuss it on the Tech Forum tomorrow?

https://www.trustedfirmware.org/meetings/tf-m-technical-forum/

 

Thanks,

Anton

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Roman Mazurak via TF-M
Sent: Tuesday, September 28, 2021 2:05 PM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Proposal to separate vendor components

 

Hi all,

 

The goal of this proposal is to separate TF-M core and platform code to simplify development and support.

 

Take, for example, the Cypress PSoC 64 platform, we see that a significant amount of code can be committed into the repository.

For end user perspective, it doesn't seem logical that project source tree has a lot of irrelevant stuff. It complicates a performance of IDE, searching and analyzing a code.

 

Pros :

Platform support can be provided separately without the need to upgrade outdated platforms or problematic platforms :

https://lists.trustedfirmware.org/pipermail/tf-m/2021-January/001454.html

https://developer.trustedfirmware.org/w/collaboration/project-maintenance-process

 

It should help to avoid or at least to minimize number of patches that requires fixes in platform folders :

https://lists.trustedfirmware.org/pipermail/tf-m/2019-April/000162.html

 

Reduces the amount of work for core team by delegating promotion of a new API support to vendors :

https://lists.trustedfirmware.org/pipermail/tf-m/2019-November/000506.html

 

Proposed solution :

There are other projects that face a similar situation, for example OpenWRT, Yocto, Android. Their common feature is that they have many dependencies. The solution they propose is based on the fact that these projects have their own build infrastructure. The user's task is to create a configuration in which you can add your own components.

In its current state, the TF-M already has some tools to implement platform as an external dependency. The user can specify the path to the platform using the TFM_PLATFORM variable. There is also work underway to implement support of external test infrastructure. (https://lists.trustedfirmware.org/pipermail/tf-m/2021-September/001824.html).

 

There is a need to add support of external secure partitions instead of current solution (https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/services/tfm_secure_partition_addition.html). I can't say if this issue is directly related to the platform, but it's possible that it will give more opportunities to vendors or will be a useful tool for adding new platforms.

 

The last question that needs to be addressed is how to link the sources supplied by vendors (platforms or security partitions) to the TF-M sources. Using the git submodule mechanism probably is not a good solution. There are two options :

  1. Platforms, security partitions and test-suits will be listed as a submodule in the TF-M tree. But this approach will not actually solve the main problem of delegating more responsibility to vendors and breaking the connection between the vendors component and TF-M.
  2. The TF-M source tree will be specified as a submodule in modules supplied by vendors. In this case we will have more problems. Because if the user's project will use two or more vendor components (for example, platform and custom security partitions), then TF-M will be mentioned more than once and it is quite possible to have several different revisions of TF-M. So, it will be impossible to properly assemble the project.

 

Therefore, I see the use of the following approach as an alternative :

  1. External components check the TF-M version using the TFM_VERSION variable.
  2. A project that uses TF-M, as well as the necessary components (platforms, external security partitions, vendor / project test suites) specifies dependencies using any method. The simplest way is to commit TF-M and vendor components as submodules in the user project.
  3. Paths to all dependencies should be transferred from the project to necessary parts of TF-M via CMake variables.

This should be equally convenient for platforms vendors, TF-M components vendors, and TF-M end users.

 

Risks :

If the project assembled by end user will use several vendor modules (for example platform and custom security partitions). It is possible that the TF-M version required by different vendors modules will be different. But this problem is present at the moment, because any significant change to the TF-M API generates many problems that need to be solved for all supported platforms (mentioned in the pros).

 

Any feedbacks are welcome.

 

Best regards,

Roman