On Fri, 16 Oct 2015 19:11:35 +0200
Thomas Monjalon wrote:
> To sum it up,
> We want to remove the need of the out-of-tree module igb_uio.
> 3 possible implementations were discussed so far:
> - new UIO driver
> - extend uio_pci_generic
> - VFIO without IOMMU
There is recent progress on VFIO with
To sum it up,
We want to remove the need of the out-of-tree module igb_uio.
3 possible implementations were discussed so far:
- new UIO driver
- extend uio_pci_generic
- VFIO without IOMMU
It is preferred to avoid creating yet another module to support.
That's why the uio_pci_generic extension wou
On 10/06/15 18:00, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 05:49:21PM +0300, Vlad Zolotarov wrote:
and read/write the config space.
This means that a single userspace bug is enough to corrupt kernel
memory.
Could u, pls., provide and example of this simple bug? Because it's
absolute
On 10/06/2015 05:07 PM, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 03:15:57PM +0300, Avi Kivity wrote:
btw, (2) doesn't really add any insecurity. The user could already poke at
the msix tables (as well as perform DMA); they just couldn't get a useful
interrupt out of them.
Poking at
On Tue, Oct 06, 2015 at 05:49:21PM +0300, Vlad Zolotarov wrote:
> >and read/write the config space.
> >This means that a single userspace bug is enough to corrupt kernel
> >memory.
>
> Could u, pls., provide and example of this simple bug? Because it's
> absolutely not obvious...
Stick a value th
On 10/06/15 16:58, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 11:23:11AM +0300, Vlad Zolotarov wrote:
Michael, how this or any other related patch is related to the problem u r
describing?
The above ability is there for years and if memory serves me
well it was u who wrote uio_pci_gener
On Tue, Oct 06, 2015 at 03:15:57PM +0300, Avi Kivity wrote:
> btw, (2) doesn't really add any insecurity. The user could already poke at
> the msix tables (as well as perform DMA); they just couldn't get a useful
> interrupt out of them.
Poking at msix tables won't cause memory corruption unless
On Tue, Oct 06, 2015 at 11:23:11AM +0300, Vlad Zolotarov wrote:
> Michael, how this or any other related patch is related to the problem u r
> describing?
> The above ability is there for years and if memory serves me
> well it was u who wrote uio_pci_generic with this "security flaw". ;)
I answe
On Tue, Oct 06, 2015 at 08:33:56AM +0100, Stephen Hemminger wrote:
> Other than implementation objections, so far the two main arguments
> against this reduce to:
> 1. If you allow UIO ioctl then it opens an API hook for all the crap out
> of tree UIO drivers to do what they want.
> 2. If
On 10/06/2015 10:33 AM, Stephen Hemminger wrote:
Other than implementation objections, so far the two main arguments
against this reduce to:
1. If you allow UIO ioctl then it opens an API hook for all the crap out
of tree UIO drivers to do what they want.
2. If you allow UIO MSI-X the
On 10/06/15 01:49, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 01:09:55AM +0300, Vladislav Zolotarov wrote:
How about instead of trying to invent the wheel just go and attack the problem
directly just like i've proposed already a few times in the last days: instead
of limiting the UIO li
Other than implementation objections, so far the two main arguments
against this reduce to:
1. If you allow UIO ioctl then it opens an API hook for all the crap out
of tree UIO drivers to do what they want.
2. If you allow UIO MSI-X then you are expanding the usage of userspace
device
On Tue, Oct 06, 2015 at 01:09:55AM +0300, Vladislav Zolotarov wrote:
> How about instead of trying to invent the wheel just go and attack the problem
> directly just like i've proposed already a few times in the last days: instead
> of limiting the UIO limit the users that are allowed to use UIO to
On 10/01/2015 05:04 PM, Stephen Hemminger wrote:
On Thu, 1 Oct 2015 16:40:10 -0700
Alexander Duyck wrote:
Do you really need to map IORESOURCE bars? Most drivers I can think of
don't use IO BARs anymore. Maybe we could look at just dropping the
code and adding it back later if we have a use
On 10/01/2015 05:01 PM, Stephen Hemminger wrote:
On Thu, 1 Oct 2015 16:40:10 -0700
Alexander Duyck wrote:
I agree with some other reviewers. Why call pci_enable_msix in open?
It seems like it would make much more sense to do this on probe, and
then disable MSI-X on free. I can only assume yo
On Thu, 1 Oct 2015 16:40:10 -0700
Alexander Duyck wrote:
> Do you really need to map IORESOURCE bars? Most drivers I can think of
> don't use IO BARs anymore. Maybe we could look at just dropping the
> code and adding it back later if we have a use case that absolutely
> needs it.
Mapping is
On Thu, 1 Oct 2015 16:40:10 -0700
Alexander Duyck wrote:
> I agree with some other reviewers. Why call pci_enable_msix in open?
> It seems like it would make much more sense to do this on probe, and
> then disable MSI-X on free. I can only assume you are trying to do it
> to save on resource
On 09/30/2015 03:28 PM, Stephen Hemminger wrote:
This driver allows using PCI device with Message Signalled Interrupt
from userspace. The API is similar to the igb_uio driver used by the DPDK.
Via ioctl it provides a mechanism to map MSI-X interrupts into event
file descriptors similar to VFIO.
18 matches
Mail list logo
