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:08 AM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> On 02/08/16 08:34, Julien Grall wrote:
>> Hi Andrew,
>>
>> On 02/08/2016 00:14, Andrew Cooper wrote:
>>> On 01/08/2016 19:15, Julien Grall wrote:
>>>> On 01/08/16 18:10, Sergej Proskurin wrote:
>>>>>
>>>>> Hello all,
>>>>
>>>> Hello Sergej,
>>>>
>>>>> The following patch series can be found on Github[0] and is part of my
>>>>> contribution to this year's Google Summer of Code (GSoC)[1]. My
>>>>> project is
>>>>> managed by the organization The Honeynet Project. As part of GSoC, I
>>>>> am being
>>>>> supervised by the Xen developer Tamas K. Lengyel
>>>>> <tamas@xxxxxxxxxxxxx>, George
>>>>> D. Webster, and Steven Maresca.
>>>>>
>>>>> In this patch series, we provide an implementation of the altp2m
>>>>> subsystem for
>>>>> ARM. Our implementation is based on the altp2m subsystem for x86,
>>>>> providing
>>>>> additional --alternate-- views on the guest's physical memory by
>>>>> means of the
>>>>> ARM 2nd stage translation mechanism. The patches introduce new HVMOPs
>>>>> and
>>>>> extend the p2m subsystem. Also, we extend libxl to support altp2m on
>>>>> ARM and
>>>>> modify xen-access to test the suggested functionality.
>>>>>
>>>>> To be more precise, altp2m allows to create and switch to additional
>>>>> p2m views
>>>>> (i.e. gfn to mfn mappings). These views can be manipulated and
>>>>> activated as
>>>>> will through the provided HVMOPs. In this way, the active guest
>>>>> instance in
>>>>> question can seamlessly proceed execution without noticing that
>>>>> anything has
>>>>> changed. The prime scope of application of altp2m is Virtual Machine
>>>>> Introspection, where guest systems are analyzed from the outside of
>>>>> the VM.
>>>>>
>>>>> Altp2m can be activated by means of the guest control parameter
>>>>> "altp2m" on x86
>>>>> and ARM architectures.  The altp2m functionality by default can also
>>>>> be used
>>>>> from within the guest by design. For use-cases requiring purely
>>>>> external access
>>>>> to altp2m, a custom XSM policy is necessary on both x86 and ARM.
>>>>
>>>> As said on the previous version, altp2m operation *should not* be
>>>> exposed to ARM guest. Any design written for x86 may not fit exactly
>>>> for ARM (and vice versa), you will need to explain why you think we
>>>> should follow the same pattern.
>>>
>>> Sorry, but I am going to step in here and disagree.  All the x86
>>> justifications for altp2m being accessible to guests apply equally to
>>> ARM, as they are hardware independent.
>>>
>>> I realise you are maintainer, but the onus is on you to justify why the
>>> behaviour should be different between x86 and ARM, rather than simply to
>>> complain at it being the same.
>>>
>>> Naturally, technical issues about the details of the implementation, or
>>> the algorithms etc. are of course fine, but I don't see any plausible
>>> reason why ARM should purposefully different from x86 in terms of
>>> available functionality, and several good reasons why it should be the
>>> same (least of all, feature parity across architectures).
>>
>> 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.
>
> Does ARM have anything like #VE whereby an in-guest entity can receive
> notification of violations?
>
> If not, then I can't see any way that an in-guest entity can usefully
> use altp2m, and by that logic, shouldn't have access to something it
> can't usefully use.

As I mentioned earlier, #VE and VMFUNC are not interdependent and
there can be use-cases just for having the altp2m switch ops and gfn
remapping, without any use mem_access and need for a #VE equivalent.
It's not our usecase so we are fine with just restricting the whole
altp2m system for the guest if that's the consensus.

>
> I suppose something could be synthesized with an event channel, if
> in-guest use is wanted/needed.

True, that might be a viable route for a #VE equivalent in the future.

Thanks,
Tamas

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