From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ed White Subject: Re: [PATCH 07/11] x86/altp2m: introduce p2m_ram_rw_ve type. Date: Fri, 16 Jan 2015 09:14:26 -0800 Message-ID: <54B946F2.9040904@intel.com> References: <1420838801-11704-1-git-send-email-edmund.h.white@intel.com> <1420838801-11704-8-git-send-email-edmund.h.white@intel.com> <20150115170344.GG57240@deinos.phlegethon.org> <54B8253E.2080900@intel.com> <54B8D7CB0200007800055B01@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54B8D7CB0200007800055B01@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: keir@xen.org, Tim Deegan , ian.jackson@eu.citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 01/16/2015 12:20 AM, Jan Beulich wrote: >>>> On 15.01.15 at 21:38, 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