From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [v8][PATCH 12/17] xen/x86/ept: handle reserved device memory in ept_handle_violation Date: Tue, 2 Dec 2014 15:26:31 -0500 Message-ID: <20141202202630.GJ357@laptop.dumpdata.com> References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com> <1417425875-9634-13-git-send-email-tiejun.chen@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1417425875-9634-13-git-send-email-tiejun.chen@intel.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: Tiejun Chen Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, tim@xen.org, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, jbeulich@suse.com, yang.z.zhang@intel.com List-Id: xen-devel@lists.xenproject.org On Mon, Dec 01, 2014 at 05:24:30PM +0800, Tiejun Chen wrote: > We always reserve these ranges since we never allow any stuff to > poke them. s/any stuff to poke them/guest to access them./ > > But in theory some untrusted VM can maliciously access them. So we > need to intercept this approach. But we just don't want to leak > anything or introduce any side affect since other OSs may touch them > by careless behavior, so its enough to have a lightweight way, and > it shouldn't be same as those broken pages which cause domain crush. s/crush/crash/ > > So we just need to return with next eip then let VM/OS itself handle s/So// s/itself// > such a scenario as its own logic. s/as its own/using its own/ > > Signed-off-by: Tiejun Chen > --- > xen/arch/x86/hvm/vmx/vmx.c | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index 2907afa..3ee884a 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -2403,6 +2403,7 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa) > p2m_type_t p2mt; > int ret; > struct domain *d = current->domain; > + struct p2m_get_reserved_device_memory pgrdm; > > /* > * We treat all write violations also as read violations. > @@ -2438,6 +2439,23 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa) > __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d); > } > > + /* This means some untrusted VM can maliciously access reserved > + * device memory. But we just don't want to leak anything or > + * introduce any side affect since other OSs may touch them by > + * careless behavior, so its enough to have a lightweight way. > + * Here we just need to return with next eip then let VM/OS itself > + * handle such a scenario as its own logic. > + */ > + pgrdm.gfn = gfn; > + pgrdm.domain = d; > + ret = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory, > + &pgrdm); > + if ( ret ) > + { > + update_guest_eip(); > + return; > + } > + > if ( qualification & EPT_GLA_VALID ) > { > __vmread(GUEST_LINEAR_ADDRESS, &gla); > -- > 1.9.1 >