Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Tue, Aug 2, 2016 at 10:40 AM, Julien Grall <julien.grall@xxxxxxx> wrote:
>
>
> On 02/08/16 17:05, George Dunlap wrote:
>>
>> On 02/08/16 16:48, Tamas K Lengyel wrote:
>>>
>>> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap <george.dunlap@xxxxxxxxxx>
>>> wrote:
>>>>
>>>> On 02/08/16 08:38, Julien Grall wrote:
>>>>>
>>>>> Hello Tamas,
>>>>>
>>>>> On 01/08/2016 21:41, Tamas K Lengyel wrote:
>>>>>>
>>>>>> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall <julien.grall@xxxxxxx>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> we did discuss whether altp2m on ARM should be exposed to guests or
>>>>>>>> not but we did not agree whether restricting it on ARM is absolutely
>>>>>>>> necessary. Altp2m was designed even on the x86 to be accessible from
>>>>>>>> within the guest on all systems irrespective of actual hardware
>>>>>>>> support for it.  Thus, this design fits ARM as well where there is
>>>>>>>> no
>>>>>>>> dedicated hardware support, from the altp2m perspective there is no
>>>>>>>> difference.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Really? I looked at the design document [1] which is Intel focus.
>>>>>>> Similar
>>>>>>> think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c).
>>>>>>
>>>>>>
>>>>>> That design cover letter mentions specifically "Both VMFUNC and #VE
>>>>>> are designed such that a VMM can emulate them on legacy CPUs". While
>>>>>> they certainly had only Intel hardware in-mind, the software route can
>>>>>> also be taken on ARM as well. As our primary use-case is purely
>>>>>> external use of altp2m we have not implemented the bits that enable
>>>>>> the injection of mem_access faults into the guest (equivalent of #VE).
>>>>>> Whether without that the altp2m switching from within the guest make
>>>>>> sense or not is beyond the scope of this series but as it could
>>>>>> technically be implemented in the future, I don't see a reason to
>>>>>> disable that possibility right away.
>>>>>
>>>>>
>>>>> The question here, is how a guest could take advantage to access to
>>>>> altp2m on ARM today? Whilst on x86 a guest could be notified about
>>>>> memaccess change, this is not yet the case on ARM.
>>>>>
>>>>> So, from my understanding, exposing this feature to a guest is like
>>>>> exposing a no-op with side effects. We should avoid to expose feature
>>>>> to
>>>>> the guest until there is a real usage and the guest could do something
>>>>> useful with it.
>>>>
>>>>
>>>> It seems like having guest altp2m support without the equivalent of a
>>>> #VE does seem pretty useless.  Would you disagree with this assessment,
>>>> Tamas?
>>>>
>>>> Every interface we expose to the guest increases the surface of attack;
>>>> so it seems like until there is a usecase for guest altp2m, we should
>>>> probably disable it.
>>>>
>>>
>>> Hi George,
>>> I disagree. On x86 using VMFUNC EPTP switching is not bound to #VE in
>>> any way. The two can certainly benefit from being used together but
>>> there is no enforced interdependence between the two. It is certainly
>>> possible to derive a use-case for just having the altp2m switch
>>> operations available to the guest. For example, I could imagine the
>>> gfn remapping be used to protect kernel memory areas against
>>> information disclosure by only switching to the accessible mapping
>>> when certain conditions are met.
>>
>>
>> That's true -- I suppose gfn remapping is something that would be useful
>> even without #VE.
>>
>>> As our usecase is purely external implementing the emulated #VE at
>>> this time has been deemed out-of-scope but it could be certainly
>>> implemented for ARM as well. Now that I'm thinking about it it might
>>> actually not be necessary to implement the #VE at all the way x86 does
>>> by injecting an interrupt as we might just be able to allow the domain
>>> to enable the existing mem_access ring directly.
>>
>>
>> That would be a possibility, but before that could be considered a
>> feature we'd need someone to go through and make sure that this
>> self-mem_access funcitonality worked properly.  (And I take it at the
>> moment that's not work you're volunteering to do.)
>>
>> But the gfn remapping is something that could be used immediately.
>
>
> I looked at the implementation of gfn remapping and I am a bit confused.
> From my understanding of the code, the same MFN could be mapped twice in the
> altp2m. Is that right? May I ask the purpose of this?
>
> So if the guest is removing the mapping from the host p2m (by calling
> XENMEM_decrease_reservation), only one of the mapping will be removed.
>
> That will leave the other mapping potentially mapped in one of the altp2m.
> However, AFAICT, x86 does take a reference on the page for mapping. So this
> may point to memory that does not belong to the domain anymore. Did I miss
> anything?
>
> After writing the above paragraphs, I noticed that p2m_change_altp2m_gfn
> seem to take care of this use case.

Right, using the min/max_remapped_gfn the p2m_altp2m_propagate_change
can check if the change involves the removal of an mfn affecting a
remap. I'm not a fan of the current implementation that just resets
the views altogether if this happens though but I can't really think
of a better way of handling it either. In the end it's easier for the
toolstack side to make sane decisions when it's removing memory from
the domain.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel