[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode
> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx] > Sent: Thursday, September 10, 2015 6:37 PM > > On Thu, Sep 10, 2015 at 02:09:39AM -0600, Jan Beulich wrote: > > >>> On 10.09.15 at 07:23, <kevin.tian@xxxxxxxxx> wrote: > > >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > > >> Sent: Wednesday, September 09, 2015 2:55 PM > > >> > > >> >>> On 09.09.15 at 03:59, <tiejun.chen@xxxxxxxxx> wrote: > > >> > @@ -2310,12 +2312,16 @@ static int intel_iommu_assign_device( > > >> > PCI_DEVFN2(bdf) == devfn && > > >> > rmrr->scope.devices_cnt > 1 ) > > >> > { > > >> > - printk(XENLOG_G_ERR VTDPREFIX > > >> > - " cannot assign %04x:%02x:%02x.%u" > > >> > + bool_t relaxed = !!(flag & XEN_DOMCTL_DEV_RDM_RELAXED); > > >> > + > > >> > + printk(XENLOG_G_WARNING VTDPREFIX > > >> > > >> Well, I can live with this always being a warning, but it's not what I > > >> had asked for. The VT-d maintainers will have to judge. > > >> > > > > > > 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'. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |