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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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

~Andrew

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