On Fri, 12 Feb 2021 at 10:11, Zongyuan Liu via Hafnium < hafnium@lists.trustedfirmware.org> wrote:
Hi,
I have been trying to understand the Arm’s FFA by reading Hafnium’s implementation, and recently discovered an inconsistency between the specification and the implementation regarding the sender’s mode of donated pages after an invocation of FFA_MEM_DONATE.
According to item 12.1 of 11.1.1.2 section in https://developer.arm.com/documentation/den0077/latest,
- If the call executes successfully, the Relayer must:
- Ensure that the state of the memory region in the participating FF-A
components is observed as follows:
- If the Receiver is a PE endpoint or a SEPID associated with a dependent
peripheral device, then: • Owner-NA for the Owner. • !Owner-NA for the Receiver.
the sender(owner) is supposed to still own the pages, which is not the case in the implementation( https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n5... ). I don’t know if there is a reason behind this, but I think at least a consequence of it is that the sender would be not able to invoke FFA_MEM_RECLAIM successfully before the receiver retrieves those pages, which implies possible “page leakage” if the receiver refuses to cooperate. I also wrote a simple test case in which the sender invokes FFA_MEM_RECLAIM right after FFA_MEM_DONATE. As expected, Hafnium returned FFA_DENIED( https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n6... ).
If it is indeed a bug, then a simple fix could be removing “| MM_MODE_UNOWNED” at line 572.
Looks like you might be right, but the fix is not quite so simple. If you only do that then when the receiver retrieves the memory region then you'll end up with both the sender and receiver owning it. So you also need to set the sender state to UNOWNED when the receiver retrieves it, and do so atomically with the update to the receiver page table. That's going to add a bunch of extra complexity unfortunately. Feel free to send a patch though!