RFC: Proposal of Integrating Trusted Firmware-A

[SgrrZhf]

Origin

trusted-firmware-a https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git

Purpose

Trusted Firmware-A (TF-A) provides a reference implementation of secure world
software for Armv7-A and Armv8-A, including a Secure Monitor executing
at Exception Level 3 (EL3). It implements various Arm interface standards,
such as:

• The Power State Coordination Interface (PSCI)_
• Trusted Board Boot Requirements CLIENT (TBBR-CLIENT)_
• SMC Calling Convention_
• System Control and Management Interface (SCMI)_
• Software Delegated Exception Interface (SDEI)_
• PSA FW update specification_

Mode of integration

As a module: it is easier to maintain and update with patches from the origin.

Module path would be modules/tee/tf-a/trusted-firmware-a

Pull Request

#46181

Description

TF-A Provides a reference implementation of secure world software for Armv7-A and Armv8-A. Such as PSCI, Trusted board boot...

Now we are trying to boot arm64 code from TF-A and use its PSCI function to support SMP. later, we will try to support more TF-A functions.

Dependencies

C compiler
GNU make
Git
OpenSSL >= 3.0 Required to build the cert_create tool.
mbed TLS == 2.28.0 Required if used Trusted Board Boot and Measured Boot

Revision

latest release version(v2.6):
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.6

License

As stated here:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/license.rst
is BSD-3-Clause.

[povergoing]

Hi @carlocaione @stephanosio, would you like to create a repo for TF-A? @SgrrZhf has prepared most of the work to integrate the TF-A, any suggestions on the next step?

[carlocaione]

Two questions:

• Why do you want it? Do you plan to have some custom zephyr patches on top?
• Instead of creating a new repo can we pull it as git submodule instead? See https://docs.zephyrproject.org/latest/develop/west/manifest.html#git-submodules-in-projects

[povergoing]

Two questions:

• Why do you want it? Do you plan to have some custom zephyr patches on top?
• Instead of creating a new repo can we pull it as git submodule instead? See https://docs.zephyrproject.org/latest/develop/west/manifest.html#git-submodules-in-projects

@SgrrZhf would you like to take a look?

[stephanosio]

Since we already have the trusted-firmware-m repository under zephyrproject-rtos, I do not see any reason why we should not do the same for trusted-firmware-a:

• It is foreseeable that we might need Zephyr-specific patches for this in the future.
• It would be good to have all upstream module repositories (listed in the main west.yml) under the GitHub zephyrproject-rtos organisation so that we have full control over them (i.e. we do not want west update to fail because git.trustedfirmware.org goes down or makes some breaking changes).

cc @nashif @MaureenHelm @carlescufi anyone opposed to creating trusted-firmware-a repository?

[carlocaione]

@stephanosio I'm not sure we will need Zephyr-specific patches TBH. And I understand the downtime problem but having TF-A as full forked module is going to add more burden on top of everything else. We are indeed trying to go in the opposite direction for some other modules already, see #44279

[SgrrZhf]

Two questions:

• Why do you want it? Do you plan to have some custom zephyr patches on top?
• Instead of creating a new repo can we pull it as git submodule instead? See https://docs.zephyrproject.org/latest/develop/west/manifest.html#git-submodules-in-projects

1. I followed the way of trusted-firmware-m, there is no modification on trusted-firmware-a now, but I don't know if we need zephyr-specific patches on it in the future.
2. Yes, I will take look at it.

[stephanosio]

having TF-A as full forked module is going to add more burden on top of everything else.

@carlocaione That OpenAMP module seems to be a special case because it adds the original repository content as a directory under the fork repository, and is not a direct Git mirror of the original repository. Obviously, we are not going to do that for trusted-firmware-a -- there is no reason to do so.

In case of trusted-firmware-a, we want to simply mirror the original trusted-firmware-a repository under zephyrproject-rtos, with the option to merge some Zephyr-specific patches as temporary workarounds if ever necessary.

We do not want to rely on external providers at least for the modules that are part of the west.yml in the zephyrproject-rtos/zephyr for the aforementioned reasons. Even if the module repository under zephyrproject-rtos is just a simple mirror tracking git.trustedfirmware.org/trusted-firmware-a, it would be good to create one because, that way, we have full control over it and can be sure that we do not have to go around updating older Zephyr releases because some breaking changes happened in git.trustedfirmware.org.

[gmarull]

@stephanosio I'm not sure we will need Zephyr-specific patches TBH. And I understand the downtime problem but having TF-A as full forked module is going to add more burden on top of everything else. We are indeed trying to go in the opposite direction for some other modules already, see #44279

I think the overall Zephyr module approach needs to be reviewed. It doesn't make sense to keep pulling more and more packages in west.yaml because only a few platforms or applications need them. One is basically forced to do something like this nowadays. All modern languages have the concept of packages, that are installed as needed by the final application (with the version needed as well). I've never understood why the Zephyr modules model is so complicated.

[stephanosio]

I think the overall Zephyr module approach needs to be reviewed. It doesn't make sense to keep pulling more and more packages in west.yaml because only a few platforms or applications need them.

Agreed, the module list for the main repository keeps growing and we need to do something about it.

The current approach of "pull everything by default" should probably be re-considered; at minimum, it should be "pull only required by default." The problem is that there is no easy way for west to resolve what modules are "required" at the moment.

Anyways, let's leave that discussion for another day (should probably create an issue to track this).

[carlescufi]

@carlocaione @stephanosio @povergoing let's not discuss the wider issue of whether we have too many entries in west.yml in this particular GitHub thread.

@carlocaione the reason for having a fork of many other projects like TF-M is not only to be able to keep any out-of-tree patches that we may requires, but also to be able to apply patches earlier than the upstream will take them, thus being able to release Zephyr according to our own schedule.

[povergoing]

@carlocaione @stephanosio @povergoing let's not discuss the wider issue of whether we have too many entries in west.yml in this particular GitHub thread.

@carlescufi Agreed, but the wider issue is raised by @gmarull, hahaha~ help you ping him

[stephanosio]

cc @microbuilder

[stephanosio]

TSC meeting 2022-06-01

@povergoing @SgrrZhf could you create a proof-of-concept pull request first so we can see what the TF-A integration would look like?

[povergoing]

TSC meeting 2022-06-01

@povergoing @SgrrZhf could you create a proof-of-concept pull request first so we can see what the TF-A integration would look like?

Sure, will do

[nashif]

TSC has approved the inclusion of this as a module, pending discussion in #46801

[SgrrZhf]

#46181
Done