[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

Jan

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

 


Rackspace

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