Thanks Oliver,

Actually, I want to simply use the Cactus OS as the initial test environment, and finally replace it. Because Cactus is easier to understand (but OP-TEE is more complex).

Also, I want to use the Hafnium (with SEL2 extension) to manage the multiple Cactus OSes, and route the "SMC" calls to the corresponding OS.

According to your words, I think I should

(1) Create a service to receive SMC calls from Normal World OS, which includes specific smc_fid, like this.

DECLARE_RT_SVC(
helloworld,
OEN_TAP_START,
OEN_TAP_END,
SMC_TYPE_FAST,
arm_arch_helloworld_init,
arm_arch_helloworld_smc_handler
);

(2) In the handler, "ERET" it to Hafnium, and then "ERET" to specific Cactus OSes according to the smc_fid

(3) Modify the Cactus OS to handle it.

Is it right? If NOT, I may consider to use OP-TEE.

Sincerely,

Wang Chenxu

Olivier Deprez <Olivier.Deprez@arm.com> 于2021年9月27日周一下午3:37写道：

Hi,

Few background questions to understand the request better:
-Is the intent to enable the SEL2 arch extension, or use the legacy model without secure virtualization?
-Do you intend to use Cactus as an initial test environment with a final goal is to replace it by a real TOS?
-If the ask is about how to write a TA, did you consider existing solutions like OP-TEE and relevant documentation?

In general TA refers to a SW component running at SEL0 on top of a TOS at SEL1.
What you call "Cactus OS" is really just a sample test payload running at SEL1.
It's not a TOS in terms of loading Trusted Applications, providing services (system calls), managing memory and IPC.

The starting point should be the FF-A specification (https://developer.arm.com/documentation/den0077/latest/).
You can repurpose Cactus to host a service at SEL1, which can be called by the NWd (TFTF test framework).
There is normally no need to modify EL3.

The below sample illustrate the message passing between TFTF at NS EL2, and Cactus at SEL1:
TFTF: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime_services/secure_service/test_ffa_direct_messaging.c#n66
cactus: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_tests/cactus_test_direct_messaging.c#n12

Please also have a look at the component documentation:
https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partition-manager.html

Depending on what you want to achieve, there are also solutions around SEL0 partitions (not involving a TOS), or the Trusted Services project.

Regards,
Olivier.

________________________________________
From: TF-A <tf-a-bounces@lists.trustedfirmware.org> on behalf of Chenxu Wang via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 27 September 2021 05:44
To: tf-a@lists.trustedfirmware.org
Subject: [TF-A] How to write a Trsuted Application?

Hi all,

I want to write a TA which will be called from the Normal World and be handled by a specific Trusted OS. Currently, I am using 3 Cactus OS (provided by TF-A-Tests) in SEL1, and a Hafnium in SEL2. Here is my partial building cmd

make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 ARM_ARCH_MINOR=4 PLAT=fvp DEBUG=1 BL33=../tf-a-tests/build/fvp/debug/tftf.bin BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json all fip

I have created some EL3 services at services/std_svc, but have not created a TA.
In my view, to call the TA, I think I should pass (1) the ID of the TA (but I am not sure how to get the ID) (2) several parameters, which may be loaded into registers. Here may be a calling process.

ldr x0,=0xdeadbeef // loading ID
ldr x1,=0x11111 // input parameters
ldr x2,=0x22222 // input parameters
smc #0

Then I think I should write a corresponding handler (of the TA) in Cactus OS. When we call "smc #0", EL3 will trap it, and route it to a specific TA.

However, I don't know how to do it. Can you provide some useful examples?

Sincerely,
Wang Chenxu