New subject: FFA Memory Management Interfaces

22 Oct 2020


      Hello Andrew,
Thank you for your addressing our questions on the previous email.
The section 5.4 of the spec defines ownership as "... software attribute that determines if a component can grant access to a memory region to anothercomponent."
The same section also defines the accesses that a component may have on a memory region.
I prepared the following patch: https://review.trustedfirmware.org/c/hafnium/hafnium/+/6521. It explicitly saves the access the sender had prior to the memory send operation, and restores that same value at a memory reclaim. This change makes the code generic, as it complies with all use-cases.
Also the patch: https://review.trustedfirmware.org/c/hafnium/hafnium/+/6471. Assuming the use-cases where the owner does not have execute permissions, the receiver's permissions will be set as NX if the Instruction Access is not specified.
Would you be able to review the changes?
Let us know if you have any concerns regarding those patches.
Best regards,
João Alves
________________________________
From: Andrew Walbran
Sent: Tuesday, October 20, 2020 5:06 PM
To: Olivier Deprez
Cc: Joao Alves; hafnium@lists.trustedfirmware.org
Subject: Re: [Hafnium] FFA Memory Management Interfaces
On Tue, 20 Oct 2020 at 16:51, Olivier Deprez <Olivier.Deprez@arm.commailto: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/aarch...
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.orgmailto:hafnium-bounces@lists.trustedfirmware.org> on behalf of Andrew Walbran via Hafnium <hafnium@lists.trustedfirmware.orgmailto:hafnium@lists.trustedfirmware.org>
Sent: 20 October 2020 17:37
To: Joao Alves
Cc: hafnium@lists.trustedfirmware.orgmailto:hafnium@lists.trustedfirmware.org
Subject: Re: [Hafnium] FFA Memory Management Interfaces
On Tue, 20 Oct 2020 at 11:18, Joao Alves <Joao.Alves@arm.commailto: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.commailto: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.commailto: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