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 08:56:02 +0800 Message-ID: <55F226A2.3000404@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> 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 >> > > Need to have separate warning/error level for relax/strict. >> > > >> > > 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? Thanks Tiejun