Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel