Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Stephen Hemminger]

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 without IOMMU. This looks the most promising
long term solution.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Thomas Monjalon]

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 would be nice.
In my understanding, there are currently 2 issues with the patches
from Vlad and Stephen:
- IRQ must be mapped to a fd without using a new ioctl
- MSI-X handling in userspace breaks the memory protection

I'm confident the first issue can be fixed with something like sysfs.
About the "security" concern, mainly expressed by MST, I think the idea
of Avi (below) deserves to be discussed.

2015-10-06 15:15, Avi Kivity:
> 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 then you are expanding the usage of userspace
> >   device access in an insecure manner.
[...]
> 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.
> 
> Maybe a module parameter "allow_insecure_dma" can be added to 
> uio_pci_generic.  Without the parameter, bus mastering and msix is 
> disabled, with the parameter it is allowed.  This requires the sysadmin 
> to take a positive step in order to make use of their hardware.

Giving the control of the memory protection level to the distribution or
the administrator looks a good idea.
When allowing insecure DMA, a log will make clear how it is supported
-or not- by the system provider.

>From another thread:
2015-10-01 14:09, Michael S. Tsirkin:
> If Linux keeps enabling hacks, no one will bother doing the right thing.
> Upstream inclusion is the only carrot Linux has to make people do the
> right thing.

The "right thing" should be guided by the users needs at a given time.
The "carrot" for a better solution will be to have a well protected system.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Stephen Hemminger]

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 without IOMMU. This looks the most promising
long term solution.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Thomas Monjalon]

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 would be nice.
In my understanding, there are currently 2 issues with the patches
from Vlad and Stephen:
- IRQ must be mapped to a fd without using a new ioctl
- MSI-X handling in userspace breaks the memory protection

I'm confident the first issue can be fixed with something like sysfs.
About the "security" concern, mainly expressed by MST, I think the idea
of Avi (below) deserves to be discussed.

2015-10-06 15:15, Avi Kivity:
> 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 then you are expanding the usage of userspace
> >   device access in an insecure manner.
[...]
> 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.
> 
> Maybe a module parameter "allow_insecure_dma" can be added to 
> uio_pci_generic.  Without the parameter, bus mastering and msix is 
> disabled, with the parameter it is allowed.  This requires the sysadmin 
> to take a positive step in order to make use of their hardware.

Giving the control of the memory protection level to the distribution or
the administrator looks a good idea.
When allowing insecure DMA, a log will make clear how it is supported
-or not- by the system provider.

>From another thread:
2015-10-01 14:09, Michael S. Tsirkin:
> If Linux keeps enabling hacks, no one will bother doing the right thing.
> Upstream inclusion is the only carrot Linux has to make people do the
> right thing.

The "right thing" should be guided by the users needs at a given time.
The "carrot" for a better solution will be to have a well protected system.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Vlad Zolotarov]

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
absolutely not obvious...

Stick a value that happens to match a kernel address in Msg Addr field
in an unmasked MSI-X entry.


This patch neither configures MSI-X entries in the user space nor 
provides additional means to do so therefore this "sticking" would be a 
matter of some extra code that is absolutely unrelated to this patch. 
So, this example seems absolutely irrelevant to this particular discussion.


thanks,
vlad





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Avi Kivity]

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 msix tables won't cause memory corruption unless msix and bus
mastering is enabled.


It's a given that bus mastering is enabled.  It's true that msix is 
unlikely to be enabled, unless msix support is added.



   It's true root can enable msix and bus mastering
through sysfs - but that's easy to block or detect. Even if you don't
buy a security story, it seems less likely to trigger as a result
of a userspace bug.


If you're doing DMA, that's the least of your worries.

Still, zero-mapping the msix space seems reasonable, and can protect 
userspace from silly stuff.  It can't be considered to have anything to 
do with security though, as long as users can simply DMA to every bit of 
RAM in the system they want to.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Michael S. Tsirkin]

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 that happens to match a kernel address in Msg Addr field
in an unmasked MSI-X entry.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Vlad Zolotarov]

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_generic with this "security flaw".  ;)

I answered all this already.

This patch enables bus mastering, enables MSI or MSI-X


This may be done from the user space right now without this patch...


, and requires
userspace to map the MSI-X table


Hmmm... I must have missed this requirement. Could u, pls., clarify? 
From what I see, MSI/MSI-X table is configured completely in the kernel 
here...



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...




uio_pci_generic does not enable bus mastering or MSI, and
it might be a good idea to have uio_pci_generic block
access to MSI/MSI-X config.


Since device bars may be mapped bypassing the UIO/uio_pci_generic - this 
won't solve any issue.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Michael S. Tsirkin]

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 msix and bus
mastering is enabled.  It's true root can enable msix and bus mastering
through sysfs - but that's easy to block or detect. Even if you don't
buy a security story, it seems less likely to trigger as a result
of a userspace bug.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Michael S. Tsirkin]

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 answered all this already.

This patch enables bus mastering, enables MSI or MSI-X, and requires
userspace to map the MSI-X table and read/write the config space.
This means that a single userspace bug is enough to corrupt kernel
memory.

uio_pci_generic does not enable bus mastering or MSI, and
it might be a good idea to have uio_pci_generic block
access to MSI/MSI-X config.
-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Michael S. Tsirkin]

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 you allow UIO MSI-X then you are expanding the usage of userspace
>  device access in an insecure manner.

That's not all. Without MSI one can detect insecure usage by detecting
userspace enabling bus mastering.  This can be detected simply using
lspci.  Or one can also imagine a configuration where this ability is
disabled, is logged, or taints kernel.  This seems like something that
might be worth having for some locked-down systems.

OTOH enabling MSI requires enabling bus mastering so suddenly we have no
idea whether device can be/is used in a safe way.

> 
> Another alternative which I explored was making a version of VFIO that
> works without IOMMU. It solves #1 but actually increases the likely negative
> response to arguent #2.

No - because VFIO has limited protection against device misuse by
userspace, by limiting access to sub-ranges of device BARs and config
space.  For a device that doesn't do DMA, that will be enough to make it
secure to use.

That's a pretty weak excuse to support userspace drivers for PCI devices
without an IOMMU, but it's the best I heard so far.

Is that worth the security trade-off? I'm still not sure.

> This would keep same API, and avoid having to
> modify UIO. But we would still have the same (if not more resistance)
> from IOMMU developers who believe all systems have to be secure against
> root.

"Secure against root" is a confusing way to put it IMHO. We are talking
about memory protection.

So that's not IOMMU developers IIUC. I believe most kernel developers will
agree it's not a good idea to let userspace corrupt kernel memory.
Otherwise, the driver can't be supported, and maintaining upstream
drivers that can't be supported serves no useful purpose.  Anyone can
load out of tree ones just as well.

VFIO already supports MSI so VFIO developers already have a lot of
experience with these issues. Getting their input would be valuable.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Avi Kivity]

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 then you are expanding the usage of userspace
  device access in an insecure manner.

Another alternative which I explored was making a version of VFIO that
works without IOMMU. It solves #1 but actually increases the likely negative
response to arguent #2. This would keep same API, and avoid having to
modify UIO. But we would still have the same (if not more resistance)
from IOMMU developers who believe all systems have to be secure against
root.


vfio's charter was explicitly aiming for modern setups with iommus.

This could be revisited, but I agree it will have even more resistance, 
justified IMO.


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.


Maybe a module parameter "allow_insecure_dma" can be added to 
uio_pci_generic.  Without the parameter, bus mastering and msix is 
disabled, with the parameter it is allowed.  This requires the sysadmin 
to take a positive step in order to make use of their hardware.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Vlad Zolotarov]

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 limit the users that are allowed to use UIO to privileged
users only (e.g. root). This would solve all clearly unresolvable issues u are
raising here all together, wouldn't it?

No - root or no root, if the user can modify the addresses in the MSI-X
table and make the chip corrupt random memory, this is IMHO a non-starter.


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".  ;)


This patch in general only adds the ability to receive notifications per 
MSI-X interrupt and it has nothing to do with the ability to reprogram 
the MSI-X related registers from the user space which was always there.




And tainting kernel is not a solution - your patch adds a pile of
code that either goes completely unused or taints the kernel.
Not just that - it's a dedicated userspace API that either
goes completely unused or taints the kernel.


--
MST


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Stephen Hemminger]

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 access in an insecure manner.

Another alternative which I explored was making a version of VFIO that
works without IOMMU. It solves #1 but actually increases the likely negative
response to arguent #2. This would keep same API, and avoid having to
modify UIO. But we would still have the same (if not more resistance)
from IOMMU developers who believe all systems have to be secure against
root.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Michael S. Tsirkin]

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 that happens to match a kernel address in Msg Addr field
in an unmasked MSI-X entry.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Avi Kivity]

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 msix tables won't cause memory corruption unless msix and bus
mastering is enabled.


It's a given that bus mastering is enabled.  It's true that msix is 
unlikely to be enabled, unless msix support is added.



   It's true root can enable msix and bus mastering
through sysfs - but that's easy to block or detect. Even if you don't
buy a security story, it seems less likely to trigger as a result
of a userspace bug.


If you're doing DMA, that's the least of your worries.

Still, zero-mapping the msix space seems reasonable, and can protect 
userspace from silly stuff.  It can't be considered to have anything to 
do with security though, as long as users can simply DMA to every bit of 
RAM in the system they want to.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Stephen Hemminger]

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 access in an insecure manner.

Another alternative which I explored was making a version of VFIO that
works without IOMMU. It solves #1 but actually increases the likely negative
response to arguent #2. This would keep same API, and avoid having to
modify UIO. But we would still have the same (if not more resistance)
from IOMMU developers who believe all systems have to be secure against
root.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Vlad Zolotarov]

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 limit the users that are allowed to use UIO to privileged
users only (e.g. root). This would solve all clearly unresolvable issues u are
raising here all together, wouldn't it?

No - root or no root, if the user can modify the addresses in the MSI-X
table and make the chip corrupt random memory, this is IMHO a non-starter.


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".  ;)


This patch in general only adds the ability to receive notifications per 
MSI-X interrupt and it has nothing to do with the ability to reprogram 
the MSI-X related registers from the user space which was always there.




And tainting kernel is not a solution - your patch adds a pile of
code that either goes completely unused or taints the kernel.
Not just that - it's a dedicated userspace API that either
goes completely unused or taints the kernel.


--
MST


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Michael S. Tsirkin]

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 msix and bus
mastering is enabled.  It's true root can enable msix and bus mastering
through sysfs - but that's easy to block or detect. Even if you don't
buy a security story, it seems less likely to trigger as a result
of a userspace bug.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Avi Kivity]

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 then you are expanding the usage of userspace
  device access in an insecure manner.

Another alternative which I explored was making a version of VFIO that
works without IOMMU. It solves #1 but actually increases the likely negative
response to arguent #2. This would keep same API, and avoid having to
modify UIO. But we would still have the same (if not more resistance)
from IOMMU developers who believe all systems have to be secure against
root.


vfio's charter was explicitly aiming for modern setups with iommus.

This could be revisited, but I agree it will have even more resistance, 
justified IMO.


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.


Maybe a module parameter "allow_insecure_dma" can be added to 
uio_pci_generic.  Without the parameter, bus mastering and msix is 
disabled, with the parameter it is allowed.  This requires the sysadmin 
to take a positive step in order to make use of their hardware.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Michael S. Tsirkin]

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 you allow UIO MSI-X then you are expanding the usage of userspace
>  device access in an insecure manner.

That's not all. Without MSI one can detect insecure usage by detecting
userspace enabling bus mastering.  This can be detected simply using
lspci.  Or one can also imagine a configuration where this ability is
disabled, is logged, or taints kernel.  This seems like something that
might be worth having for some locked-down systems.

OTOH enabling MSI requires enabling bus mastering so suddenly we have no
idea whether device can be/is used in a safe way.

> 
> Another alternative which I explored was making a version of VFIO that
> works without IOMMU. It solves #1 but actually increases the likely negative
> response to arguent #2.

No - because VFIO has limited protection against device misuse by
userspace, by limiting access to sub-ranges of device BARs and config
space.  For a device that doesn't do DMA, that will be enough to make it
secure to use.

That's a pretty weak excuse to support userspace drivers for PCI devices
without an IOMMU, but it's the best I heard so far.

Is that worth the security trade-off? I'm still not sure.

> This would keep same API, and avoid having to
> modify UIO. But we would still have the same (if not more resistance)
> from IOMMU developers who believe all systems have to be secure against
> root.

"Secure against root" is a confusing way to put it IMHO. We are talking
about memory protection.

So that's not IOMMU developers IIUC. I believe most kernel developers will
agree it's not a good idea to let userspace corrupt kernel memory.
Otherwise, the driver can't be supported, and maintaining upstream
drivers that can't be supported serves no useful purpose.  Anyone can
load out of tree ones just as well.

VFIO already supports MSI so VFIO developers already have a lot of
experience with these issues. Getting their input would be valuable.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Michael S. Tsirkin]

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 answered all this already.

This patch enables bus mastering, enables MSI or MSI-X, and requires
userspace to map the MSI-X table and read/write the config space.
This means that a single userspace bug is enough to corrupt kernel
memory.

uio_pci_generic does not enable bus mastering or MSI, and
it might be a good idea to have uio_pci_generic block
access to MSI/MSI-X config.
-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Vlad Zolotarov]

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
absolutely not obvious...

Stick a value that happens to match a kernel address in Msg Addr field
in an unmasked MSI-X entry.


This patch neither configures MSI-X entries in the user space nor 
provides additional means to do so therefore this "sticking" would be a 
matter of some extra code that is absolutely unrelated to this patch. 
So, this example seems absolutely irrelevant to this particular discussion.


thanks,
vlad





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Vlad Zolotarov]

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_generic with this "security flaw".  ;)

I answered all this already.

This patch enables bus mastering, enables MSI or MSI-X


This may be done from the user space right now without this patch...


, and requires
userspace to map the MSI-X table


Hmmm... I must have missed this requirement. Could u, pls., clarify? 
From what I see, MSI/MSI-X table is configured completely in the kernel 
here...



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...




uio_pci_generic does not enable bus mastering or MSI, and
it might be a good idea to have uio_pci_generic block
access to MSI/MSI-X config.


Since device bars may be mapped bypassing the UIO/uio_pci_generic - this 
won't solve any issue.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Michael S. Tsirkin]

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 privileged
> users only (e.g. root). This would solve all clearly unresolvable issues u are
> raising here all together, wouldn't it?

No - root or no root, if the user can modify the addresses in the MSI-X
table and make the chip corrupt random memory, this is IMHO a non-starter.

And tainting kernel is not a solution - your patch adds a pile of
code that either goes completely unused or taints the kernel.
Not just that - it's a dedicated userspace API that either
goes completely unused or taints the kernel.

> >
> > --
> > MST
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Michael S. Tsirkin]

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 privileged
> users only (e.g. root). This would solve all clearly unresolvable issues u are
> raising here all together, wouldn't it?

No - root or no root, if the user can modify the addresses in the MSI-X
table and make the chip corrupt random memory, this is IMHO a non-starter.

And tainting kernel is not a solution - your patch adds a pile of
code that either goes completely unused or taints the kernel.
Not just that - it's a dedicated userspace API that either
goes completely unused or taints the kernel.

> >
> > --
> > MST
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Alexander Duyck]

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 case that absolutely
needs it.

Mapping is not strictly necessary, but for virtio it acts a way to communicate
the regions.


I think I see what you are saying.  I was hoping we could get away from 
having to map any I/O ports but it looks like virtio is still using them 
for BAR 0, or at least that is what I am seeing on my VM with 
virtio_net.  I was really hoping we could get away from that since a 16b 
address space is far too restrictive anyway.



Also how many devices actually need resources beyond BAR 0?  I'm just
curious as I know BAR 2 on many of the Intel devices is the register
space related to MSI-X so now we have both the PCIe subsystem and user
space with access to this region.

VMXNet3 needs 2 bars. Most use only one.


So essentially we are needing to make exceptions for the virtual interfaces.

I guess there isn't much we can do then and we probably need to map any 
and all base address registers we can find for the given device.  I was 
hoping for something a bit more surgical since we are opening a security 
hole of sorts, but I guess it can't be helped if we want to support 
multiple devices and they all have such radically different configurations.


- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Alexander Duyck]

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 you are trying to do it
to save on resources but the fact is this is a driver you have to
explicitly force onto a device so you would probably be safe to assume
that they plan to use it in the near future.

Because if interface is not up, the MSI handle doesn't have to be open.
This saves resources and avoids some races.


Yes, but it makes things a bit messier for the interrupts.  Most drivers 
take care of interrupts during probe so that if there are any allocation 
problems they can take care of them then instead of leaving an interface 
out that will later fail when it is brought up.  It ends up being a way 
to deal with the whole MSI-X fall-back issue.


- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Stephen Hemminger]

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 not strictly necessary, but for virtio it acts a way to communicate
the regions.

> Also how many devices actually need resources beyond BAR 0?  I'm just 
> curious as I know BAR 2 on many of the Intel devices is the register 
> space related to MSI-X so now we have both the PCIe subsystem and user 
> space with access to this region.

VMXNet3 needs 2 bars. Most use only one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Stephen Hemminger]

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 resources but the fact is this is a driver you have to 
> explicitly force onto a device so you would probably be safe to assume 
> that they plan to use it in the near future.

Because if interface is not up, the MSI handle doesn't have to be open.
This saves resources and avoids some races.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Alexander Duyck]

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.

VFIO is a better choice if IOMMU is available, but often userspace drivers
have to work in environments where IOMMU support (real or emulated) is
not available.  All UIO drivers that support DMA are not secure against
rogue userspace applications programming DMA hardware to access
private memory; this driver is no less secure than existing code.

Signed-off-by: Stephen Hemminger 
---
  drivers/uio/Kconfig  |   9 ++
  drivers/uio/Makefile |   1 +
  drivers/uio/uio_msi.c| 378 +++
  include/uapi/linux/Kbuild|   1 +
  include/uapi/linux/uio_msi.h |  22 +++
  5 files changed, 411 insertions(+)
  create mode 100644 drivers/uio/uio_msi.c
  create mode 100644 include/uapi/linux/uio_msi.h

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 52c98ce..04adfa0 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -93,6 +93,15 @@ config UIO_PCI_GENERIC
  primarily, for virtualization scenarios.
  If you compile this as a module, it will be called uio_pci_generic.

+config UIO_PCI_MSI
+   tristate "Generic driver supporting MSI-x on PCI Express cards"
+   depends on PCI
+   help
+ Generic driver that provides Message Signalled IRQ events
+ similar to VFIO. If IOMMMU is available please use VFIO
+ instead since it provides more security.
+ If you compile this as a module, it will be called uio_msi.
+
  config UIO_NETX
tristate "Hilscher NetX Card driver"
depends on PCI


Should you maybe instead depend on CONFIG_PCI_MSI.  Without MSI this is 
essentially just uio_pci_generic with a bit more greedy mapping setup.



diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 8560dad..62fc44b 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_UIO_NETX)  += uio_netx.o
  obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
  obj-$(CONFIG_UIO_MF624) += uio_mf624.o
  obj-$(CONFIG_UIO_FSL_ELBC_GPCM)   += uio_fsl_elbc_gpcm.o
+obj-$(CONFIG_UIO_PCI_MSI)  += uio_msi.o
diff --git a/drivers/uio/uio_msi.c b/drivers/uio/uio_msi.c
new file mode 100644
index 000..802b5c4
--- /dev/null
+++ b/drivers/uio/uio_msi.c
@@ -0,0 +1,378 @@
+/*-
+ *
+ * Copyright (c) 2015 by Brocade Communications Systems, Inc.
+ * Author: Stephen Hemminger 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 only.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_VERSION "0.1.1"
+#define MAX_MSIX_VECTORS   64
+
+/* MSI-X vector information */
+struct uio_msi_pci_dev {
+   struct uio_info info;   /* UIO driver info */
+   struct pci_dev *pdev;   /* PCI device */
+   struct mutexmutex;  /* open/release/ioctl mutex */
+   int ref_cnt;/* references to device */
+   unsigned intmax_vectors;/* MSI-X slots available */
+   struct msix_entry *msix;/* MSI-X vector table */
+   struct uio_msi_irq_ctx {
+   struct eventfd_ctx *trigger; /* vector to eventfd */
+   char *name; /* name in /proc/interrupts */
+   } *ctx;
+};
+


I would move the definition of uio_msi_irq_ctx out of uio_msi_pci_dev. 
It would help to make this a bit more readable.



+static irqreturn_t uio_intx_irqhandler(int irq, void *arg)
+{
+   struct uio_msi_pci_dev *udev = arg;
+
+   if (pci_check_and_mask_intx(udev->pdev)) {
+   eventfd_signal(udev->ctx->trigger, 1);
+   return IRQ_HANDLED;
+   }
+
+   return IRQ_NONE;
+}
+


I would really prefer to see the intx handling dropped since there are 
already 2 different UIO drivers setup for handling INTx style 
interrupts.  Lets focus on the parts from the last decade and drop 
support for INTx now in favor of MSI-X and maybe MSI.  If we _REALLY_ 
need it we can always come back later and add it.



+static irqreturn_t uio_msi_irqhandler(int irq, void *arg)
+{
+   struct eventfd_ctx *trigger = arg;
+
+   eventfd_signal(trigger, 1);
+   return IRQ_HANDLED;
+}
+
+/* set the mapping between vector # and existing eventfd. */
+static int set_irq_eventfd(struct uio_msi_pci_dev *udev, u32 vec, int fd)
+{
+   struct eventfd_ctx *trigger;
+   int irq, err;
+
+   if (vec >= udev->max_vectors) {
+   dev_notice(>pdev->dev, "vec %u >= num_vec %u\n",
+  vec, udev->max_vectors);
+   return -ERANGE;
+   }
+
+   irq = udev->msix[vec].vector;
+   trigger = 

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Alexander Duyck]

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.

VFIO is a better choice if IOMMU is available, but often userspace drivers
have to work in environments where IOMMU support (real or emulated) is
not available.  All UIO drivers that support DMA are not secure against
rogue userspace applications programming DMA hardware to access
private memory; this driver is no less secure than existing code.

Signed-off-by: Stephen Hemminger 
---
  drivers/uio/Kconfig  |   9 ++
  drivers/uio/Makefile |   1 +
  drivers/uio/uio_msi.c| 378 +++
  include/uapi/linux/Kbuild|   1 +
  include/uapi/linux/uio_msi.h |  22 +++
  5 files changed, 411 insertions(+)
  create mode 100644 drivers/uio/uio_msi.c
  create mode 100644 include/uapi/linux/uio_msi.h

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 52c98ce..04adfa0 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -93,6 +93,15 @@ config UIO_PCI_GENERIC
  primarily, for virtualization scenarios.
  If you compile this as a module, it will be called uio_pci_generic.

+config UIO_PCI_MSI
+   tristate "Generic driver supporting MSI-x on PCI Express cards"
+   depends on PCI
+   help
+ Generic driver that provides Message Signalled IRQ events
+ similar to VFIO. If IOMMMU is available please use VFIO
+ instead since it provides more security.
+ If you compile this as a module, it will be called uio_msi.
+
  config UIO_NETX
tristate "Hilscher NetX Card driver"
depends on PCI


Should you maybe instead depend on CONFIG_PCI_MSI.  Without MSI this is 
essentially just uio_pci_generic with a bit more greedy mapping setup.



diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 8560dad..62fc44b 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_UIO_NETX)  += uio_netx.o
  obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
  obj-$(CONFIG_UIO_MF624) += uio_mf624.o
  obj-$(CONFIG_UIO_FSL_ELBC_GPCM)   += uio_fsl_elbc_gpcm.o
+obj-$(CONFIG_UIO_PCI_MSI)  += uio_msi.o
diff --git a/drivers/uio/uio_msi.c b/drivers/uio/uio_msi.c
new file mode 100644
index 000..802b5c4
--- /dev/null
+++ b/drivers/uio/uio_msi.c
@@ -0,0 +1,378 @@
+/*-
+ *
+ * Copyright (c) 2015 by Brocade Communications Systems, Inc.
+ * Author: Stephen Hemminger 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 only.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_VERSION "0.1.1"
+#define MAX_MSIX_VECTORS   64
+
+/* MSI-X vector information */
+struct uio_msi_pci_dev {
+   struct uio_info info;   /* UIO driver info */
+   struct pci_dev *pdev;   /* PCI device */
+   struct mutexmutex;  /* open/release/ioctl mutex */
+   int ref_cnt;/* references to device */
+   unsigned intmax_vectors;/* MSI-X slots available */
+   struct msix_entry *msix;/* MSI-X vector table */
+   struct uio_msi_irq_ctx {
+   struct eventfd_ctx *trigger; /* vector to eventfd */
+   char *name; /* name in /proc/interrupts */
+   } *ctx;
+};
+


I would move the definition of uio_msi_irq_ctx out of uio_msi_pci_dev. 
It would help to make this a bit more readable.



+static irqreturn_t uio_intx_irqhandler(int irq, void *arg)
+{
+   struct uio_msi_pci_dev *udev = arg;
+
+   if (pci_check_and_mask_intx(udev->pdev)) {
+   eventfd_signal(udev->ctx->trigger, 1);
+   return IRQ_HANDLED;
+   }
+
+   return IRQ_NONE;
+}
+


I would really prefer to see the intx handling dropped since there are 
already 2 different UIO drivers setup for handling INTx style 
interrupts.  Lets focus on the parts from the last decade and drop 
support for INTx now in favor of MSI-X and maybe MSI.  If we _REALLY_ 
need it we can always come back later and add it.



+static irqreturn_t uio_msi_irqhandler(int irq, void *arg)
+{
+   struct eventfd_ctx *trigger = arg;
+
+   eventfd_signal(trigger, 1);
+   return IRQ_HANDLED;
+}
+
+/* set the mapping between vector # and existing eventfd. */
+static int set_irq_eventfd(struct uio_msi_pci_dev *udev, u32 vec, int fd)
+{
+   struct eventfd_ctx *trigger;
+   int irq, err;
+
+   if (vec >= udev->max_vectors) {
+   dev_notice(>pdev->dev, "vec %u >= num_vec %u\n",
+  vec, udev->max_vectors);
+   return -ERANGE;
+   }
+
+   irq = 

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Stephen Hemminger]

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 not strictly necessary, but for virtio it acts a way to communicate
the regions.

> Also how many devices actually need resources beyond BAR 0?  I'm just 
> curious as I know BAR 2 on many of the Intel devices is the register 
> space related to MSI-X so now we have both the PCIe subsystem and user 
> space with access to this region.

VMXNet3 needs 2 bars. Most use only one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Alexander Duyck]

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 you are trying to do it
to save on resources but the fact is this is a driver you have to
explicitly force onto a device so you would probably be safe to assume
that they plan to use it in the near future.

Because if interface is not up, the MSI handle doesn't have to be open.
This saves resources and avoids some races.


Yes, but it makes things a bit messier for the interrupts.  Most drivers 
take care of interrupts during probe so that if there are any allocation 
problems they can take care of them then instead of leaving an interface 
out that will later fail when it is brought up.  It ends up being a way 
to deal with the whole MSI-X fall-back issue.


- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Stephen Hemminger]

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 resources but the fact is this is a driver you have to 
> explicitly force onto a device so you would probably be safe to assume 
> that they plan to use it in the near future.

Because if interface is not up, the MSI handle doesn't have to be open.
This saves resources and avoids some races.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

[Alexander Duyck]

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 case that absolutely
needs it.

Mapping is not strictly necessary, but for virtio it acts a way to communicate
the regions.


I think I see what you are saying.  I was hoping we could get away from 
having to map any I/O ports but it looks like virtio is still using them 
for BAR 0, or at least that is what I am seeing on my VM with 
virtio_net.  I was really hoping we could get away from that since a 16b 
address space is far too restrictive anyway.



Also how many devices actually need resources beyond BAR 0?  I'm just
curious as I know BAR 2 on many of the Intel devices is the register
space related to MSI-X so now we have both the PCIe subsystem and user
space with access to this region.

VMXNet3 needs 2 bars. Most use only one.


So essentially we are needing to make exceptions for the virtual interfaces.

I guess there isn't much we can do then and we probably need to map any 
and all base address registers we can find for the given device.  I was 
hoping for something a bit more surgical since we are opening a security 
hole of sorts, but I guess it can't be helped if we want to support 
multiple devices and they all have such radically different configurations.


- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/