linux-kernel - 答复: [PATCH] USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <0b5dc3873aca42199f769e82288a2b3b@zhaoxin.com>
Date:   Tue, 28 Jul 2020 05:53:39 +0000
From:   WeitaoWang-oc <WeitaoWang-oc@...oxin.com>
To:     Alex Williamson <alex.williamson@...hat.com>
CC:     Alan Stern <stern@...land.harvard.edu>,
        Greg KH <gregkh@...uxfoundation.org>,
        "mathias.nyman@...ux.intel.com" <mathias.nyman@...ux.intel.com>,
        "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "hslester96@...il.com" <hslester96@...il.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Carsten_Schmid@...tor.com" <Carsten_Schmid@...tor.com>,
        "efremov@...ux.com" <efremov@...ux.com>,
        "Tony W. Wang(XA-RD)" <TonyWWang@...oxin.com>,
        "Cobe Chen(BJ-RD)" <CobeChen@...oxin.com>,
        "Tim Guo(BJ-RD)" <TimGuo@...oxin.com>,
        "wwt8723@....com" <wwt8723@....com>
Subject: 答复: [PATCH] USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci


On Fri, 24 Jul 2020 19:17:49 +0000 Alex wrote:
> On Fri, 24 Jul 2020 12:57:49 +0000
> WeitaoWang-oc <WeitaoWang-oc@...oxin.com> wrote:
> 
> > On Thu, 23 Jul 2020 12:38:21 -0400, Alan wrote:
> > > On Thu, Jul 23, 2020 at 10:17:35AM -0600, Alex Williamson wrote:
> > > > The IOMMU grouping restriction does solve the hardware issue, so long
> > > > as one driver doesn't blindly assume the driver private data for
> > > > another device and modify it.
> > >
> > > Correction: The IOMMU grouping restriction solves the hardware issue for
> > > vfio-pci.  It won't necessarily help if some other driver comes along
> > > and wants to bind to this hardware.
> > >
> > > >   I do agree that your solution would
> > > > work, requiring all devices are unbound before any can be bound, but it
> > > > also seems difficult to manage.  The issue is largely unique to USB
> > > > AFAIK.  On the other hand, drivers coordinating with each other to
> > > > register their _private_ data as share-able within a set of drivers
> > > > seems like a much more direct and explicit interaction between the
> > > > drivers.  Thanks,
> > >
> > > Yes, that makes sense.  But it would have to be implemented in the
> > > driver core, not in particular subsystems like USB or PCI.  And it might
> > > be seen as overkill, given that only UHCI/OHCI/EHCI devices require this
> > > sort of sharing AFAIK.
> > >
> > > Also, when you think about it, what form would such coordination among
> > > drivers take?  From your description, it sounds like the drivers would
> > > agree to avoid accessing each other's private data if the proper
> > > registration wasn't in place.
> > >
> > > On the other hand, a stronger and perhaps more robust approach would be
> > > to enforce the condition that non-cooperating drivers are never bound to
> > > devices in the same group at the same time.  That's basically what I'm
> > > proposing here -- the question is whether the enforcement should be
> > > instituted in the kernel or should merely be part of a standard protocol
> > > followed by userspace drivers.
> > >
> > > Given that it's currently needed in only one place, it seems reasonable
> > > to leave this as a "gentlemen's agreement" in userspace for the time
> > > being instead of adding it to the kernel.
> > >
> >
> > Provided that EHCI and UHCI host controller declare not support P2P and
> > ACS. So, we can assign EHCI and UHCI host controller to different IOMMU
> > group separately. We assign EHCI host controller to host and assign UHCI
> > host controller to VM. Then, ehci_hcd driver load/unload operation in host
> > will cause the same issue as discussed
> 
> And you have an example of such a device?  I expect these do not exist,
> nor should they.  It seems like it would be an improper use of ACS.
> Thanks,


In kernel source code tree drivers/pci/quirks.c,
There is a device list declared by pci_dev_acs_enabled. In which list, such as 
multi-function device without acs capability not allow peer-to-peer bewteen 
functions. Those device can be assign to to different IOMMU group separately.

Thnaks
weitao