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
Hi Samarth,
There are 2 ways to map RXTX buffers which are both exercised by different cactus partitions. The first and second cactus partitions define the buffers in their manifest [1], whereas the third partition doesn't and then maps the buffer during it's initialisation, hence the if (ffa_id == (SPM_VM_ID_FIRST + 2)) condition [2]. This is why when you try map the buffers for SPM_VM_ID_FIRST it fails, these buffers have already been mapped when the partition manifest was parsed.
With regards to whether it is possible to map buffers from the secure world, it is, an SP can create a buffer pair with the SPMC. I believe the check you mentioned in spmd_main.c [3] is required to enforce rule 2 from the 6.2.2.2 Buffer Setup Section in the FF-A EAC0 spec [4]. 2) The Hypervisor allocates the buffer pair it shares with the SPM. It uses the FFA_RXTX_MAP ABI to map this buffer pair in the SPMC’s translation regime. Because of this FFA_RXTX_MAP_SMC64 should never be forwarded from the SPMC to SPMD.
I hope this helps, please let me know if you have any other questions. Kind Regards, Daniel
[1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/he... [2] https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/he... [3] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+... [4] https://developer.arm.com/documentation/den0077/latest
Hi Samarth,
Depending on what you aim for, you could try to use Trusted Services [1] as a "framework" for SP development. Some highlights what benefits going with TS would provide: - examples for S-EL0 SPs (we have numerous SPs in the repo already) - capability to fetch external components. Ability to: - clone a git repository - override dependency info captured in cmake files - use pre-fetched source code - use pre-built binary - a pattern for platform abstraction and portability - a pattern for portability between SPMC implementations - currently we focus on the OP-TEE SPMC, but the project structure could accommodate S-EL1 SPs too. - cmake based build system - established testing methodology - tests to target host machine (x86) natively - tests to target arm HW. (Currently we use FVP).
The current focus is on S-EL0 SPs,.
If what you do is Hafnium specific the existing tight integration of Cactus to the Hafnium infrastructure can be a value which you may wish to build on. Still AFAIK Cactus was designed to be a test payload and I am not sure how well it could be "productized". Others: please chime in if I am mistaken here.
Note: TS is still not a mature project and thus expect some raw edges.
You can find some TS related presentations here: https://developer.trustedfirmware.org/w/trusted-services/public_videos_and_p...
[1]: https://trusted-services.readthedocs.io/en/integration/
/George
-----Original Message----- From: samarthparikh via TF-A-Tests tf-a-tests@lists.trustedfirmware.org Sent: 27 April 2022 13:02 To: tf-a-tests tf-a-tests@lists.trustedfirmware.org Cc: samarthp samarthp@ymail.com Subject: [Tf-a-tests] [cactus] Configuring & mapping mailbox failing
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
tf-a-tests@lists.trustedfirmware.org
-
daniel.boulby＠arm.com -
Gyorgy Szing -
samarthparikh