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

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

On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
>
>
> On 01/08/2016 20:20, Tamas K Lengyel wrote:
>>
>> On Mon, Aug 1, 2016 at 12:15 PM, Julien Grall <julien.grall@xxxxxxx>
>> 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.
>>>
>>> Speaking about security, I skimmed through the series and noticed that a
>>> lot
>>> of my previous comments have not been addressed. For instance there are
>>> still no locking on the altp2m operations and a guest could disable
>>> altp2m.
>>>
>>> I will give a look to the rest of the series once this is fixed.
>>>
>>
>> Julien,
>> 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.

Tamas

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