[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.