Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

[Ed White <edmund.h.white@xxxxxxxxx>]

On 01/09/2015 02:41 PM, Andrew Cooper wrote:
> On 09/01/2015 22:21, Ed White wrote:
>> On 01/09/2015 02:06 PM, Andrew Cooper wrote:
>>> On 09/01/2015 21:26, Ed White wrote:
>>>> This set of patches adds support to hvm domains for EPTP switching by 
>>>> creating
>>>> multiple copies of the host p2m (currently limited to 10 copies).
>>>>
>>>> The primary use of this capability is expected to be in scenarios where 
>>>> access
>>>> to memory needs to be monitored and/or restricted below the level at which 
>>>> the
>>>> guest OS page tables operate. Two examples that were discussed at the 2014 
>>>> Xen
>>>> developer summit are:
>>> Given the nature of VMFUNC, I presume this series is looking to add
>>> support for in-guest entities to be able to monitor/tweak/swap the EPT
>>> tables under the feet of operating system around it?
>>>
>> Primarily, yes.
> 
> Cool!  It might be helpful to add a sentence or two to this effect in
> the description.
> 

Point taken. The first slide deck linked below describes the intra-domain
use case in some detail, but I should at least mention it here. I'll add
something next time round.

>> There is (untested) support for using these capabilities
>> cross-domain, because we have been contacted by multiple people who are
>> interested in using them that way, but the hardware acceleration provided
>> by VMFUNC and #VE aren't available cross-domain.
>>
>>>>     VM introspection: 
>>>>         http://www.slideshare.net/xen_com_mgr/
>>>>         zero-footprint-guest-memory-introspection-from-xen
>>>>
>>>>     Secure inter-VM communication:
>>>>         http://www.slideshare.net/xen_com_mgr/nakajima-nvf
>>>>
>>>> Each p2m copy is populated lazily on EPT violations, and only contains 
>>>> entries for
>>>> ram p2m types. Permissions for pages in alternate p2m's can be changed in 
>>>> a similar
>>>> way to the existing memory access interface, and gfn->mfn mappings can be 
>>>> changed.
>>>>
>>>> All this is done through extra HVMOP types.
>>>>
>>>> The cross-domain HVMOP code has been compile-tested only. Also, the 
>>>> cross-domain
>>>> code is hypervisor-only, the toolstack has not been modified.
>>>>
>>>> The intra-domain code has been tested. Violation notifications can only be 
>>>> received
>>>> for pages that have been modified (access permissions and/or gfn->mfn 
>>>> mapping) 
>>>> intra-domain, and only on VCPU's that have enabled notification.
>>>>
>>>> VMFUNC and #VE will both be emulated on hardware without native support.
>>>>
>>>> This code is not compatible with nested hvm functionality and will refuse 
>>>> to work
>>>> with nested hvm active. It is also not compatible with migration. It 
>>>> should be
>>>> considered experimental.
>>> What about shared ept, pci passthrough, ballooning, PoD or any other
>>> mechanisms which involve playing games with the EPT tables behind the
>>> back of the guest?
>>>
>>> It appears that this feature only makes sense for a plain, RAM-only VM
>>> with no bells or whistles.
>>>
>> The intention is that only RAM will be tweaked, which is why only RAM entries
>> exist in the alternate p2m's. All those other page types are still valid and
>> still handled in the primary nested page fault handler, but these mechanisms
>> can't modify them.
>>
>> Also, if any page that was previously plain old RAM is changed in the host 
>> p2m,
>> one of the later patches in the series immediately removes it from all the
>> alternates, so 'stale' copies in the alternates shouldn't be an issue.
> 
> Ok so the plain old ram tricks are possibly ok, but that still sounds
> like shared ept and pci passthrough are still to be avoided?
> 
> Having some non-OS part of the guest swap the EPT tables and
> accidentally turn a DMA buffer read-only is not going to end well.
> 

The agent can certainly do bad things, and at some level you have to assume it
is sensible enough not to. However, I'm not sure this is fundamentally more
dangerous than what a privileged domain can do today using the MEMOP...
operations, and people are already using those for very similar purposes.

Ed


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