Hi,
We are trying to create a secure partition based on cactus.
In cactus_main.c there is a mapping of rxtx region for SPM_VM_ID_FIRST + 2. In our case, there would be just one sp and so we are doing the same for SPM_VM_ID_FIRST itself but it goes into panic.
On checking TF-A code, in file spmd_main.c the request FFA_RXTX_MAP_SMC64 is not allowed to be invoked from secure world. So, in any case when CONFIGURE_AND_MAP_MAILBOX which internally calls ffa_rxtx_map and which further invokes smc for FFA_RXTX_MAP_SMC64, it will always fail.
So should the RXTX mailbox always be mapped from Normal World? If that is the correct understanding, then we are confused with the use of CONFIGURE_AND_MAP_MAILBOX in cactus_main.c
The purpose for setting up this RXTX channel is mainly because cactus memory sharing test requires it and we are writing a small test to share memory from non-secure world.
Any clarity, suggestions would be helpful.
Regards,
Samarth
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(a)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…
> cactus:
> https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_…
>
> Please also have a look at the component documentation:
>
> https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit…
>
> 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(a)lists.trustedfirmware.org> on behalf of Chenxu
> Wang via TF-A <tf-a(a)lists.trustedfirmware.org>
> Sent: 27 September 2021 05:44
> To: tf-a(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
>
Hi all,
I want to write a TA which will be called from the Normal World and be
handled by specific Cactus OS.
Specifically, 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
Hi,
On 7/8/19 4:30 PM, Sandrine Bailleux via TF-A-Tests wrote:
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Sorry, please do not pay attention to the confidentiality notice in my
previous email, it was a mistake.
Regards,
Sandrine
Hi Damianos,
On 7/8/19 3:47 PM, Damianos Veskoukis via TF-A-Tests wrote:
> Is there a way to run newly written tests (on the fly) without closing and rerunning the FVP executable with the new binary each time?
No, unfortunately this is not possible at the moment. I am afraid you
have to restart the FVP executable every time you change the tftf.bin
file, like you said.
Regards,
Sandrine
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
Is there a way to run newly written tests (on the fly) without closing and rerunning the FVP executable with the new binary each time?
Thank you
Dear all,
This is a test email. Please ignore it and sorry for the inconvenience.
Kind regards,
John
--
<https://www.arm.com/>
John Tsichritzis | Graduate Software Engineer
Email : john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com>
110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom
Hello Alamy,
> There is a Makefile dependency problem regarding the "tests_list.h" as it mentioned in
> https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/docs/change-log.rst
>
> I have a fix to that (in one way) but not perfect:
> https://github.com/AlamyLiu/tf-a-tests/commit/33929aca35c7ad65e9acde7126059…
Thanks for your patch! I see that you've pushed it to Github, could you
please post it to the official Gerrit review server instead? We conduct
code reviews on https://review.trustedfirmware.org/ The contribution
guidelines are highlighted in the following document:
https://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/contributing.rst
> I think the root cause is that
>
> * It uses `eval` in Makefile to `do` the job that should be done by `make`.
> * Makefile should have only the `rules` (none), not the action (verb - eval) for compiling.
>
> Using `eval` to compile the code hide the information to `make`.
> Let `make` know the rules & dependency so the problem could be solved cleanly.
I agree with you. The build system would need to be re-designed for
better clarity and ease of maintenance.
The build system of TF-A Tests is inherited from TF-A, which
unfortunately had these issues already. We are planning to rework the
TF-A build system in the future (see
https://lists.trustedfirmware.org/pipermail/tf-a/2018-December/000000.html).
When that work is complete, I'm hoping we'll be able to import it in
TF-A Tests as well.
Regards,
Sandrine
Hi developers,
There is a Makefile dependency problem regarding the "tests_list.h" as it mentioned in
https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/docs/change-log.rst
I have a fix to that (in one way) but not perfect:
https://github.com/AlamyLiu/tf-a-tests/commit/33929aca35c7ad65e9acde7126059…
I think the root cause is that
* It uses `eval` in Makefile to `do` the job that should be done by `make`.
* Makefile should have only the `rules` (none), not the action (verb - eval) for compiling.
Using `eval` to compile the code hide the information to `make`.
Let `make` know the rules & dependency so the problem could be solved cleanly.
P.S.:
The workaround is `make -j1`. Which has self-described the dependency problem.
Regards,
Alamy
Hi,
I'm currently investigating ways to improve the output of the TF-A
Tests. This email serves as a proposal. Feedback is welcome.
Attached are 2 text files:
- old-output.txt
Shows an extract of how the UART output looks like today.
- new-output.txt
Shows an extract of how I propose we present this information in the future.
With this, I hope to improve:
1) Conciseness.
- Duplicated test results are removed.
Tests results are reported as we go along, like they are today but in a
more concise way. The final summary no longer repeats individual tests
results but instead indicates the success or failure of the entire test
suite. (A test suite is marked as passed if all of its tests have either
passed or have been skipped.) as well as the total number of
skipped/passed/... tests (see at line 57).
- The unnecessary CPU ID headers are removed.
Most of the lines no longer indicate which CPU printed them. This will
always be the primary CPU so this information seems useless.
Messages printed by tests continue to print the CPU ID as before.
However, instead of printing the CPU MPIDR (e.g. [CPU 0x0001]), the CPU
linear index (as returned by the platform_get_core_pos() function) is
displayed. It is shorter, while providing the same information.
Messages printed by tests are prefixed by T: (see an example at line 28)
to make them stand out among the other framework messages.
2) More human-friendly.
3) Reasonably script-friendly.
E.g.: The final string at line 77 is only there for our Continuous
Integration tools to identify the end of the test session.
Regards,
Sandrine Bailleux
