Sorry for chiming in late. Whether or not the FF-A spec forbids exchanging executable pages, it would be better as a general rule to limit execute permissions to an SP, unless explicitly requested by the SP. I cant think of a reason why an SP would need to take donated NS memory and map it as an executable page unless it generates code or loads new code at run time. This, in my mind, is just another attack vector and potential "feature" to misuse, in case SP's don't sanitize pages for ex. I would be okay with limiting all memory exchanges between NWd and SWd to only operate on RW and have NX enabled always, unless there is an explicit use case some one comes up with that requires it. Also, shared pages between NWd and SWd should definitely not have execute permissions.
Thanks Raghu
-----Original Message----- From: Hafnium hafnium-bounces@lists.trustedfirmware.org On Behalf Of Andrew Walbran via Hafnium Sent: Tuesday, October 20, 2020 9:07 AM To: Olivier Deprez Olivier.Deprez@arm.com Cc: hafnium@lists.trustedfirmware.org Subject: Re: [Hafnium] FFA Memory Management Interfaces
On Tue, 20 Oct 2020 at 16:51, Olivier Deprez Olivier.Deprez@arm.com wrote:
Hi Andrew,
On the first question it relates to this line
https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008/8/src/arch /aarch64/hypervisor/other_world.c#92
and whether we should map the "Hypervisor VM" pages as RWX provided a SP must never execute from an NS memory region. So it should never happen that a VM grants execute permissions to an NS buffer shared to a SP.
I don't think it can happen if the memory region is shared, but why shouldn't an SP be allowed to retrieve a memory region donated or lent from a normal world VM to map as executable? Is there something in the FF-A spec that forbids that, or some reason we wouldn't want to allow it?
Or should this be enforced by the Relayer/SPMC on a mem retrieve that an NS memory region will always be mapped RW / NX?
Regards, Olivier.
From: Hafnium hafnium-bounces@lists.trustedfirmware.org on behalf of Andrew Walbran via Hafnium hafnium@lists.trustedfirmware.org Sent: 20 October 2020 17:37 To: Joao Alves Cc: hafnium@lists.trustedfirmware.org Subject: Re: [Hafnium] FFA Memory Management Interfaces
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_memor y.c#n393
<
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memor y.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_memor y.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_memor y.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_memor y.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
hafnium@lists.trustedfirmware.org
-
raghu.ncstate＠icloud.com