Re: [Xen-devel] [PATCH] vpci: don't allow access to devices not assigned to the domain

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:jbeulich@xxxxxxxx]
> Sent: Monday, September 2, 2019 7:58 PM
> 
> On 02.09.2019 13:30, Roger Pau Monne wrote:
> > Don't allow the hardware domain to access the PCI config space of
> > devices not assigned to it. Ie: the config space of iommu devices
> > in use by Xen should not be accessible to the hardware domain.
> 
> Well, I agree with what you say above, but the code change disallows
> much more than this. In particular Dom0 (and maybe stub domains too)
> need to be able to access the config space of devices assigned to
> guests, e.g. for qemu to control MSI and/or MSI-X.
> 
> > --- a/xen/drivers/vpci/vpci.c
> > +++ b/xen/drivers/vpci/vpci.c
> > @@ -319,7 +319,21 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int
> reg, unsigned int size)
> >      /* Find the PCI dev matching the address. */
> >      pdev = pci_get_pdev_by_domain(d, sbdf.seg, sbdf.bus, sbdf.devfn);
> >      if ( !pdev )
> > +    {
> > +        pcidevs_lock();
> > +        pdev = pci_get_pdev(sbdf.seg, sbdf.bus, sbdf.devfn);
> > +        pcidevs_unlock();
> 
> The locking here points out a pre-existing issue: While
> pci_get_pdev_by_domain() doesn't check that the pcidevs lock is
> being held, it really should. It not doing so is (I guess) because
> VT-d code too looks to be violating this. Kevin - thoughts?
> 

It's used by addr_to_dma_page_maddr, while the latter is used
in many code paths. Some of them already holds the lock while
others don't. Instead of introducing trickiness in those paths, I
think this may be fixed in an easier way - just removing the 
invocation of pci_get_pdev_by_domain. The only purpose of
current usage is to find the related DRHD, and then do NUMA-
aware page table allocation. It's needless to repeat finding DRHD
here. We can just record it when assign_device happens.

Let's tweak a fix for it.

Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel