From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode Date: Fri, 11 Sep 2015 10:20:51 +0800 Message-ID: <55F23A83.5010906@intel.com> References: <1441763998-4937-1-git-send-email-tiejun.chen@intel.com> <55EFF3CE02000078000A1150@prv-mh.provo.novell.com> <55F156E302000078000A18B4@prv-mh.provo.novell.com> <20150910103720.GG8496@zion.uk.xensource.com> <55F226A2.3000404@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Tian, Kevin" , Wei Liu , Jan Beulich Cc: "Zhang, Yang Z" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org >> >> > > However I don't think this patch is a right fix. So far relax/strict policy >> >> > > is per-domain. what about one VM specifies relax while another VM >> >> > > specifies strict when each is assigned with a device sharing rmrr >> >> > > with the other? In that case it becomes a system-wide security hole. >> >> > >> >> > The one specifying "strict" won't gets its device assigned (due to >> >> > the code above, taking the path that was there already without >> >> > the patch), so I don't see the security issue. >> >> > >> >> >> >> Agreed. A VM can't get such device assigned in the first place, so the >> >> hypothetical scenario doesn't exist. >> >> >> > >> > Sorry it's a bad example. My actual concern is that we can't count >> > on this per-VM relax/strict policy to prevent group devices assigned >> > to different VM. In that case it's definitely a security hole since >> > one VM may clobber shared RMRR to impact another VM. So right >> > example for that scenario is both VMs specified with 'relax'. >> >> What if one of group devices is still owned by Dom0? >> > > It's also risky since other VM may attack Dom0 in such scenario. > In my opinion, Dom0 should have a big impact... Anyway, this always means we have to start refactoring some codes. For example, we are probably going to introduce some new fields in struct acpi_rmrr_unit, just like, int domain_id -> Distinguish which domain owns this unit unsigned int flag -> Record state: XEN_DOMCTL_DEV_RDM_RELAXE or !XEN_DOMCTL_DEV_RDM_RELAXE This should involve several sections, such as parsing rmrr, setup hwdomain and assign/remove device. But I'm not sure if this is good to handle current problem. Actually I prefer to work on current patch just now, and then we can start discussing our final solution :) Thanks Tiejun