On Tue, 20 Oct 2020 at 11:18, Joao Alves Joao.Alves@arm.com wrote:
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 patch https://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)?*
Is there any reason we need to restrict it to NX? Usually a VM owning memory implies that it has full RWX access to it, as it would without a hypervisor involved. We assume that it should be able to grant any subset of those permissions when donating or lending the memory, subject to FF-A or other policy restrictions.
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_mode https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n393 https://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 change https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008. *@Andrew Walbran qwandor@google.com, is the change I provided correct? Or is there a reason for the current implementation of 'ffa_memory_permissions_to_mode'?*
Again, the assumption is that the owner of a page always has full access to it. From the FF-A spec, section 5.11.2.2 says "In a transaction to donate memory... if the receiver is a PE, the owner must not specify the level of access". Section 5.11.3.2 says the same thing for the execute permission in the case of donating or lending to a single borrower. The spec says that the retriever should specify the permissions it wants, but it is not required. So in these cases the retriever may specify any permissions, and if it doesn't specify any then we give it full access.
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_reclaim https://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_transition https://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 Walbran qwandor@google.com would you be able to provide any comments on this?*
Our assumption, as above, is that the initial owner of a page starts with full access to it, and so this is what should be restored when it is reclaimed.
Please let me know if anyone has any comments/questions.
Best regards, João Alves