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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.01.15 at 18:14, <edmund.h.white@xxxxxxxxx> wrote:
> 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?

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.

Jan


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