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

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

On 01/16/2015 12:20 AM, Jan Beulich wrote:
>>>> On 15.01.15 at 21:38, <edmund.h.white@xxxxxxxxx> wrote:
>> On 01/15/2015 09:03 AM, Tim Deegan wrote:
>>> At 13:26 -0800 on 09 Jan (1420806397), Ed White wrote:
>>>> This is treated exactly like p2m_ram_rw, except that suppress_ve is not
>>>> set in the EPTE.
>>>
>>> I don't think this is going to work -- you probably want to support
>>> p2m_ram_ro at least, and maybe other types, but duplicating each of
>>> them as a 'type foo with #VE' doesn't seem right.
>>>
>>> Since the default is to set the ignore-#ve flag everywhere, how about
>>> having an operation to enable #ve for a frame that just clears that
>>> bit, and then having all other updates to altp2m entries preserve it?
>>
>> I hear you, but #VE is only even relevant for the in-domain agent
>> model, 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.
>>
>> Can we do it this way, and then change it later if required?
> 
> 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?

Ed


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