Re: [Xen-devel] Alternate p2m design specification

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

On 06/10/2015 11:23 AM, Andrew Cooper wrote:
> On 10/06/15 01:09, Ed White wrote:
>> This document describes a new capability for VM Introspection, Security and 
>> Privacy in Xen. The new capability is called âaltp2mâ (short for Alternate 
>> p2m) that is used to provide the ability for Xen to host alternate guest 
>> physical memory domains for a specific guest-domain. This document describes 
>> the overall design specific to Xen for your review and feedback.
> 
> This is a very thorough description, and everything here seems in order.
> 
> A couple of remarks,
> 
>> The altp2m functionality allows the capability to be used via an agent 
>> operating in an HVM guest or alternately an agent operating in a separate 
>> privileged domain. For cross domain operation, an XSM hook is defined such 
>> that the administrator can define a policy for inter-domain VM introspection.
> 
> There should be an interlock to prevent both an internal and external
> entity from actually being able to use the altp2m infrastructure.
> 
> Nothing good can come of an uncoordinated attempt like this, whereas a
> coordinated use would already have to be communicating far more than the
> hypercalls themselves would allow.
> 

I have to disagree with you on that. Assuming we have the XSM hooks right,
you could enforce either/or through policy, but we have envisaged scenarios
where we would want to mix internal and external use of the hypercalls.

> 
> Also, hardware accelerated altp2m is mutually exclusive with EPT PML, as
> we have no way of determining which translation was in use when a gpa
> was appended to the buffer.  We are going to have to maintain a feature
> compatibility matrix.  Even for non-accelerated altp2m, the cost of
> working out the real gpa is likely prohibitive, and we should probably
> resort to declaring logdirty and altp2m as exclusive features.
> 
> ~Andrew
> 

I haven't investigated the PML code, but just to be clear, log-dirty
without PML is compatible with altp2m. We are already enforcing
either/or for nestedhvm and altp2mhvm domain parameters -- I'll
look into doing something similar for PML.

Ed


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