netdev - Re: [net-next v2 1/1] virtual-bus: Implementation of Virtual Bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 20 Nov 2019 14:11:08 -0400
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     Jason Wang <jasowang@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Parav Pandit <parav@...lanox.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        davem@...emloft.net, gregkh@...uxfoundation.org,
        Dave Ertman <david.m.ertman@...el.com>, netdev@...r.kernel.org,
        linux-rdma@...r.kernel.org, nhorman@...hat.com,
        sassmann@...hat.com, Kiran Patil <kiran.patil@...el.com>,
        Tiwei Bie <tiwei.bie@...el.com>
Subject: Re: [net-next v2 1/1] virtual-bus: Implementation of Virtual Bus

On Wed, Nov 20, 2019 at 10:28:56AM -0700, Alex Williamson wrote:
> > > Are you objecting the mdev_set_iommu_deivce() stuffs here?  
> > 
> > I'm questioning if it fits the vfio PCI device security model, yes.
> 
> The mdev IOMMU backing device model is for when an mdev device has
> IOMMU based isolation, either via the PCI requester ID or via requester
> ID + PASID.  For example, an SR-IOV VF may be used by a vendor to
> provide IOMMU based translation and isolation, but the VF may not be
> complete otherwise to provide a self contained device.  It might
> require explicit coordination and interaction with the PF driver, ie.
> mediation.  

In this case the PF does not look to be involved, the ICF kernel
driver is only manipulating registers in the same VF that the vfio
owns the IOMMU for.

This is why I keep calling it a "so-called mediated device" because it
is absolutely not clear what the kernel driver is mediating. Nearly
all its work is providing a subsystem-style IOCTL interface under the
existing vfio multiplexer unrelated to vfio requirements for DMA.

> The IOMMU backing device is certainly not meant to share an IOMMU
> address space with host drivers, except as necessary for the
> mediation of the device.  The vfio model manages the IOMMU domain of
> the backing device exclusively, any attempt to dual-host the device
> respective to the IOMMU should fault in the dma/iommu-ops.  Thanks,

Sounds more reasonable if the kernel dma_ops are prevented while vfio
is using the device.

However, to me it feels wrong that just because a driver wishes to use
PASID or IOMMU features it should go through vfio and mediated
devices.

It is not even necessary as we have several examples already of
drivers using these features without vfio.

I feel like mdev is suffering from mission creep. I see people
proposing to use mdev for many wild things, the Mellanox SF stuff in
the other thread and this 'virtio subsystem' being the two that have
come up publicly this month.

Putting some boundaries on mdev usage would really help people know
when to use it. My top two from this discussion would be:

- mdev devices should only bind to vfio. It is not a general kernel
  driver matcher mechanism. It is not 'virtual-bus'.

- mdev & vfio are not a substitute for a proper kernel subsystem. We
  shouldn't export a complex subsystem-like ioctl API through
  vfio ioctl extensions. Make a proper subsystem, it is not so hard.

Maybe others agree?

Thanks,
Jason