Re: [Xen-devel] [PATCH 07/11] x86/altp2m: introduce p2m_ram_rw_ve type.

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

>>> Without you explaining to us the full details of the in-domain
>>> agent model, I'm afraid this is going to remain dubious and the
>>> question hard to answer. In particular, if you indeed want to
>>> prohibit that behavior on _all_ other p2m types, how would
>>> subsequently changing the implementation then be compatible
>>> (if it can't be done this way right from the beginning)?
>>
>> I think I have explained it. There is software already commercially
>> available that uses a security hypervisor to partition memory at a
>> level below the OS page tables for Windows running on physical
>> hardware. We want to make that possible for Windows in a Xen domU.
>> The security hypervisor uses multiple EPTP's to apply different
>> access permissions to some guest physical addresses in different
>> views (p2m's) and in certain cases applies different
>> guest physical->host physical (gfn->mfn) mappings to some pages
>> between different views. The only pages to which any of these
>> operations is applied are pages which are rwx ram at a hardware level.
>> The security hypervisor works in concert with a protected agent that
>> runs inside the OS.
>>
>> I don't see any great difficulty at all in implementing the #VE
>> functionality through a p2m type initially and subsequently adding
>> a more generic facility. What do you see as the problem there?
> 
> You said above "and as the only current user of that model we not
> only don't want #VE to work on other page types, we specifically
> want it to be prohibited" - if in a first implementation you enforce
> this, and a later implementation relaxes it, the guest relying on the
> first implementation's behavior may break. I.e. I'm not certain
> whether with a later more complete implementation a guest
> wouldn't be required to actively request what behavior it wants,
> and whether making the default be how your first implementation
> is intended to behave is (design-/architecture-wise) reasonable.

You are right, that was a poor explanation. Our in-domain agent
should never be manipulating pages that are not hardware rwx ram,
and so if we inadvertently try to manipulate another page type
it would help us if rather than attempting to do what we asked Xen
returned an error. So it's effectively a debugging aid. I wasn't
suggesting that we would rely on that behaviour.

Ed


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