Hi Bao Peng,
Thanks for your reply and details.
As mentioned earlier, SPMD sets the secure environment differently from SPM-MM because of differing design choices mandated by the FF-A specification for the former VS implementation defined + MM specification design choices for the latter.
This is especially true when it comes to interrupt handling.(e.g. use of Exception Handling Framework for SPM-MM).
From Arm side we think this hybrid architecture opens the door to untested or undefined behaviors that we can't really support as neither mandated by the architecture nor proposed as a reference implementation.
It's ok though to attempt those modifications downstream and we can try to help on that through the ML, however this is unlikely to be supported by Arm or land upstream.
Regards, Olivier.
________________________________ From: baopeng (A) via TF-A tf-a@lists.trustedfirmware.org Sent: 23 February 2024 02:11 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Compatibility support for SPM_MM and SPMD
Hi Olivier Deprez,
We use the SPM_MM framework mainly for read/write control of security variables. We do not want to modify the original application code at this time.
At the same time we want to add support for the new SPMD framework based code.
________________________________
Hi Baopeng,
By "code based on the SPM_MM framework" I assume you refer to a secure service running in a S-EL0 partition based on the MM protocol? If you can share this information, what kind of service is this implementing? RAS handling, secure variables, TPM back end, other? What kind of interface is needed to access the service? asynchronous with interrupts? synchronous with SMC from normal world? Another question is why do you need to collocate the SPMD if the MM implementation is already achieving the scenarios you need?
Ideally you'd want to migrate this service to run on top of:
* the EL3 FF-A SPMC https://trustedfirmware-a.readthedocs.io/en/latest/components/el3-spmc.html * or if the HW/chipset implements it, the S-EL2 FF-A SPMC https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.html...
Knowing the kind of S-EL0 service would help narrowing the effort for a migration.
FF-A (https://developer.arm.com/documentation/den0077/latest/) is a modern evolution of MM (https://developer.arm.com/documentation/den0060/latest) and any functionality achieved by the MM protocol can be handled by FF-A. For example the MM_COMMUNICATE interface can be easily swapped by the FFA_MSG_SEND_DIRECT_REQ interface.
Regards, Olivier.
________________________________ From: baopeng (A) via TF-A tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Sent: 21 February 2024 07:10 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Request for help
Hi Olivier Deprez,
We have developed code based on the SPM_MM framework and do not want to reconstruct the code. However, we want to adapt the code to the SPMD framework.
What should we do?
________________________________
Hi Baopeng,
SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol. This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC). Both implementations aren't compatible and it is discouraged to attempt co-locating both. It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard.
We may help you better if you tell a bit more about the reason for mixing both implementations in the same build.
Regards, Olivier.
________________________________ From: baopeng (A) baopeng1@huawei.commailto:baopeng1@huawei.com Sent: 20 February 2024 02:19 To: tf-a-owner@lists.trustedfirmware.org tf-a-owner@lists.trustedfirmware.orgmailto:tf-a-owner@lists.trustedfirmware.org Subject: Request for help
Dear Sir/ Madam,
we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons.
However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default.
I would like to ask what is the main reason for making the current restrictions?