Hello All,
We have been working on enabling the use memory management interfaces between SWd and NWd, on Hafnium as SPMC. We identified a few points that would benefit from a general discussion/clarification through the Mailing List for this work to progress on time for the first release.
The whole memory has been mapped to a VM representative of the NWd FFA endpoints (in the code can be found as a global variable called 'other_world_vm') in this patchhttps://review.trustedfirmware.org/c/hafnium/hafnium/+/6008. All the memory is configured as RW memory, to be permissive enough to ease the validation of the sender's original permissions vs the requested sharing permissions. This approach seems valid given the following assumptions: the 'other_world_vm' is never scheduled, which means that there is no risk of memory leakage; the hypervisor should do the necessary validation of the permissions that a given NWd FFA endpoint has on a given memory region, before forwarding the handling of the operation to the SPMC.
The first point to bring to discussion is regarding the RW configuration. Is this really the best configuration we would expect for memory to be shared from NWd to the SWd? Or is this excluding any use-case we are not aware of (e.g. at this point we are restricting instruction permissions to NX)?
Whilst testing the memory management interfaces, I noticed that if the instruction access on the memory region descriptor (in the spec has been described in section 5.12, and in the code defined as 'struct ffa_memory_region') is set as 'not specified' for the Lend and Donate operations, the receiver would acquire permission to execute the memory region. This is due to the implementation of the function 'ffa_memory_permissions_to_modehttps://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n393https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n393', which sets the memory mode to MM_MODE_X for case instruction access FFA_INSTRUCTION_ACCESS_NOT_SPECIFIED. My understanding is that in such case MM_MODE_X shouldn't be set. Please check this changehttps://review.trustedfirmware.org/c/hafnium/hafnium/+/6008. @Andrew Walbranmailto:qwandor@google.com, is the change I provided correct? Or is there a reason for the current implementation of 'ffa_memory_permissions_to_mode'?
I also noticed that after a memory reclaim, the sender/owner of a memory region acquires RW and X permissions, even if these were not part of the original permissions when sending the memory region. This is due to definition of the variable 'memory_to_attributes' in the function 'ffa_memory_reclaimhttps://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n2576': uint32_t memory_to_attributes = MM_MODE_R | MM_MODE_W | MM_MODE_X; Down the call stack, the value of this variable is used to update the variable 'to_mode' in function 'ffa_retrieve_check_transitionhttps://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n665'. The value of variable 'to_mode' is later passed to 'ffa_region_group_identity_map'https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n1018 to update the owner's memory mapping. My understanding is that the sender's memory mode should be reset to the mode it had prior to the original memory send operation, and that this is going to be a problem for memory management operations (even between between VMs and between SPs). I have seen this behavior on my set, however I would like to validate my analysis. @Andrew Walbranmailto:qwandor@google.com would you be able to provide any comments on this?
Please let me know if anyone has any comments/questions.
Best regards, João Alves