>>> On 10.09.15 at 07:23, <kevin.t...@intel.com> wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Wednesday, September 09, 2015 2:55 PM >> >> >>> On 09.09.15 at 03:59, <tiejun.c...@intel.com> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel