Thank you, Gyorgy and Tamas,

The environment is TI's AM644x. Yes, it is Cortex-A + Cortex M with two additional Cortex R5 cores, but TI seems using one R5 core for boot, not the CortexM core.

Our customer is asking for the "attestation token" to verify the running image (hash) likely.
PSA seems more standard, but if CCA helps, we can go for it as well.

So, what Attestation implementation shall we go for, PSA/CCA, any recommendation.

The other issue is Yocto which I am not familiar :)
I asked someone's help to include "attestation" TS using Yocto build, by following the tutorial https://git.yoctoproject.org/meta-arm/about/documentation/trusted-services.md
> MACHINE_FEATURES:append = "arm-ffa and ts-attestation" and setting CONFIG_ARM_FFA_TRANSPORT=y

but I am getting errror like

"ERROR: Nothing PROVIDES 'ts-sp-attestation' (..../recipes-bsp/optee/optee-os_4.1.0.bb DEPENDS on or otherwise requires it) "
ts-sp-attestation was skipped

So, I am neither Linux nor yocto expert, is there any simple introdcutions for newbies?
1. How to include&build ts-attestation etc, as I am getting errors
2. How to use the drivers to interact with TSs? I searched for tstee and libts but any examples using these libraries?

Thank you in advance.



Tamas Ban <Tamas.Ban@arm.com>, 2 Ara 2024 Pzt, 13:38 tarihinde şunu yazdı:

Hi Max,

 

> Can we say this presentation (2022) is there and ready to use?

Yes, there are multiple measured boot and attestation schemes are implemented in TF-A and Trusted Services. What to use is depends on your use case and your system capability:

- A class core only

-  A+M system where the M core is in a secure enclave

> By the way, you mentioned that attestation is not handled in TF-a (EL3), but the below EL3 handler handles it (RMM_ATTEST_GET_PLAT_TOKEN). Does it just send the request to the "Trusted Service" you were referencing?

No, they are different.

The  available options/schemes:

  • -If you have a single A class core and you want something similar to psa_initial_attest_get_token() then  read this:
    https://trusted-services.readthedocs.io/en/latest/services/attest-service-description.html
    Here the token is created by a secure service running in SEL0/1. EL3 only responsible for making the world switch (S<->NS). This is callable from Linux user space, with the libs and kernel driver pointed out by George.
  • What you mentioned above (RMM_ATTEST_GET_PLAT_TOKEN) is basically the CCA attestation scheme, where there are two halves tokens. It is targeting the RME capable systems which otherwise have A+M  cores. One half of the token is produced by the M class secure enclave(HES) the other half by the RMM running in REL2 on the A core. There is a hash link between the half tokens.

Please elaborate your use case then I can help more!

Regards,
Tamas

 

From: Gyorgy Szing <Gyorgy.Szing@arm.com>
Sent: Monday, December 2, 2024 11:43 AM
To: Max Adam <maxadamcamb@gmail.com>; Tamas Ban <Tamas.Ban@arm.com>
Subject: Re: [TF-A] Interaction with TF-a from NS World

 

Hi,

 

“By the way, you mentioned that attestation is not handled in TF-a (EL3),”

Sorry, my bad. Since you mentioned PSA I got the impression you are after PSA Initial Attestation, and that is out of scope for TF-A.

Tamas: Can you please respond to the RMM related attestation question?

 

/George

 

On 2024-12-02, 11:38, "Max Adam" <maxadamcamb@gmail.com> wrote:

 

Hi Gyorgy,

 

Thank you for the detailed comment. It is really helpful, especially this link seems good to chase: https://git.yoctoproject.org/meta-arm/about/documentation/trusted-services.md

 

Basically, I was following this link from @Tamas.ban@arm.com; "CCA attestation and measured both"

 

Can we say this presentation (2022) is there and ready to use?

By the way, you mentioned that attestation is not handled in TF-a (EL3), but the below EL3 handler handles it (RMM_ATTEST_GET_PLAT_TOKEN). Does it just send the request to the "Trusted Service" you were referencing?

 

Error! Filename not specified.

 

 

 

 

Gyorgy Szing <Gyorgy.Szing@arm.com>, 2 Ara 2024 Pzt, 09:29 tarihinde şunu yazdı:

Hi Max,

 

Please check this picture [1]. It shows the exception levels on an aarch64 platforms, and typical components executing at each exception level.

 

TF-A is a Secure Monitor implementation. It is the most privileged component, and its main goal is to route calls between the NWd and SWd. Each call to SWd must go through this component. E.g. if an “aarch64 App” wishes to use a service provided by a Trusted Service, a call has to be made into EL1 (e.g. Linux Kernel), then if a Hypervisor is present to EL2, then to the Monitor at EL3 (TF-A), then to optional S-EL2 (e.g. Hafnium), S-EL1 (e.g. OP_TEE) and finally to S-EL0.
TF-A does not implement the PSA APIs.

 

OP-TEE is a Trusted OS, and a reference implementation of the Global Platforms standards [2]. PSA is not part of GP, and AFAIK there is no TA implementing PSA APIs.

 

The PSA reference implementation for Cortex-A is developed in the Trusted Services project. The project implements all services required for PSA certification (Crypto, ITS, PS, Attestation) plus a few non-psa ones like Firmware Update Service or UEFI Variable service. We developed a Linux kernel driver called tstee (up-stream since v6.10) , and two shared libraries which can be used by linux user-space applications to access the services. Libts implements service discovery and the TS RPC components, and “libtspsa” carries easy to use PSA client implementations (basically the C PSA API).

 

Trusted Services follows the Firmware Framework for A-Profile standard (FF-A) which defines a protocol to be used between exception levels and a runtime model. PSA services are deployed to S-EL0 Secure Partitions and need a Secure Partition Manager implementation executing at a higher exception levels. The reference SPMD implementation is part of the TF-A project, the S-EL2 reference SPMC is Hafnium [5], and the S-EL1 reference implementation is OP-TEE SPMC [6]. (Only one SPMC implementation can be present on a system.)

 

A major difference between the Cortex-M and the Cortex-A ecosystem is the level of diversity. While a Cortex-M stack is typically implemented using components from one or maximum a few stakeholders, a Cortex-A stack is built from components owned by a vast set of owners. As a result, integration of a Cortex-A software stack is much more complex. There are multiple integration systems targeting the problem like Buildroot and Yocto. Trusted Services supports two integration systems currently. The OP-TEE integration system, which is a gnumake and Buildroot based solution (see [7]) and Yocto where the meta-arm layer [8] hosts TS recipes. Please find some TS specific meta-arm documentation here: [9]

 

For more help and information, about PSA on Cortex-A and TS feel free to drop an email to the TS mailing list [10], and/or to me.

 

/George


1: https://documentation-service.arm.com/static/63a065c41d698c4dc521cb1b

2: https://globalplatform.org/about-globalplatform/

3: https://trusted-services.readthedocs.io/en/stable/overview/index.html

4: https://developer.arm.com/architectures/Firmware%20Framework%20for%20A-Profile

5: https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.html

6: https://optee.readthedocs.io/en/latest/architecture/spmc.html

7: https://github.com/OP-TEE/build

8: https://git.yoctoproject.org/meta-arm
9: https://git.yoctoproject.org/meta-arm/about/documentation/trusted-services.md

10: https://lists.trustedfirmware.org/mailman3/lists/trusted-services.lists.trustedfirmware.org/

 

On 2024-12-01, 21:14, "Max Adam via TF-A" <tf-a@lists.trustedfirmware.org> wrote:

 

Hello All,

 

I am coming from the TF-m domain, and now I am struggling with TF-a as I am not a Linux expert.

 

I am just looking for the interactions with TF-a, such as getting psa attestation token etc.

 

How can I find example these interactions from NS World (Linux) or lower privilege Secure World Executions such as OP-TEE or OP-TEE TAs?

 

I suppose there shall be drivers and APIs provided by TF-a?

 

Thanks

 

Max