From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, linux-kernel@vger.kernel.org
Cc: Avi Kivity <avi@scylladb.com>,
dev@dpdk.org, hjk@hansjkoch.de, gregkh@linux-foundation.org
Subject: Re: [PATCH 2/2] uio: new driver to support PCI MSI-X
Date: Fri, 16 Oct 2015 19:11:35 +0200 [thread overview]
Message-ID: <2696552.dQRxzH79dc@xps13> (raw)
In-Reply-To: <5613BB7D.3060202@scylladb.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, linux-kernel@vger.kernel.org
Cc: dev@dpdk.org, Avi Kivity <avi@scylladb.com>,
Stephen Hemminger <stephen@networkplumber.org>,
hjk@hansjkoch.de, gregkh@linux-foundation.org,
Vlad Zolotarov <vladz@cloudius-systems.com>
Subject: Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X
Date: Fri, 16 Oct 2015 19:11:35 +0200 [thread overview]
Message-ID: <2696552.dQRxzH79dc@xps13> (raw)
In-Reply-To: <5613BB7D.3060202@scylladb.com>
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.
next prev parent reply other threads:[~2015-10-16 17:12 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 22:28 [PATCH 0/2] uio_msi: device driver Stephen Hemminger
2015-09-30 22:28 ` Stephen Hemminger
2015-09-30 22:28 ` [PATCH 1/2] uio: add support for ioctls Stephen Hemminger
2015-09-30 22:28 ` Stephen Hemminger
2015-09-30 22:28 ` [PATCH 2/2] uio: new driver to support PCI MSI-X Stephen Hemminger
2015-09-30 22:28 ` Stephen Hemminger
2015-10-01 8:33 ` Michael S. Tsirkin
2015-10-01 8:33 ` Michael S. Tsirkin
2015-10-01 10:37 ` Michael S. Tsirkin
2015-10-01 10:37 ` Michael S. Tsirkin
2015-10-01 16:06 ` Michael S. Tsirkin
2015-10-01 16:06 ` Michael S. Tsirkin
2015-10-01 14:50 ` Stephen Hemminger
2015-10-01 14:50 ` Stephen Hemminger
2015-10-01 15:22 ` Michael S. Tsirkin
2015-10-01 15:22 ` Michael S. Tsirkin
2015-10-01 16:31 ` Michael S. Tsirkin
2015-10-01 16:31 ` Michael S. Tsirkin
2015-10-01 17:26 ` Stephen Hemminger
2015-10-01 17:26 ` Stephen Hemminger
2015-10-01 18:25 ` Michael S. Tsirkin
2015-10-01 18:25 ` Michael S. Tsirkin
2015-10-05 21:54 ` Michael S. Tsirkin
2015-10-05 21:54 ` Michael S. Tsirkin
2015-10-05 22:09 ` Vladislav Zolotarov
2015-10-05 22:49 ` Michael S. Tsirkin
2015-10-05 22:49 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 7:33 ` Stephen Hemminger
2015-10-06 7:33 ` [dpdk-dev] " Stephen Hemminger
2015-10-06 12:15 ` Avi Kivity
2015-10-06 12:15 ` [dpdk-dev] " Avi Kivity
2015-10-06 14:07 ` Michael S. Tsirkin
2015-10-06 15:41 ` Avi Kivity
2015-10-06 15:41 ` [dpdk-dev] " Avi Kivity
2015-10-16 17:11 ` Thomas Monjalon [this message]
2015-10-16 17:11 ` Thomas Monjalon
2015-10-16 17:20 ` Stephen Hemminger
2015-10-16 17:20 ` [dpdk-dev] " Stephen Hemminger
2015-10-06 13:42 ` Michael S. Tsirkin
2015-10-06 13:42 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 8:23 ` Vlad Zolotarov
2015-10-06 8:23 ` [dpdk-dev] " Vlad Zolotarov
2015-10-06 13:58 ` Michael S. Tsirkin
2015-10-06 13:58 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 14:49 ` Vlad Zolotarov
2015-10-06 15:00 ` Michael S. Tsirkin
2015-10-06 15:00 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 16:40 ` Vlad Zolotarov
2015-10-06 16:40 ` [dpdk-dev] " Vlad Zolotarov
2015-10-01 23:40 ` Alexander Duyck
2015-10-01 23:40 ` [dpdk-dev] " Alexander Duyck
2015-10-02 0:01 ` Stephen Hemminger
2015-10-02 0:01 ` [dpdk-dev] " Stephen Hemminger
2015-10-02 1:21 ` Alexander Duyck
2015-10-02 1:21 ` [dpdk-dev] " Alexander Duyck
2015-10-02 0:04 ` Stephen Hemminger
2015-10-02 2:33 ` Alexander Duyck
2015-10-02 2:33 ` [dpdk-dev] " Alexander Duyck
2015-10-01 8:36 ` [PATCH 0/2] uio_msi: device driver Michael S. Tsirkin
2015-10-01 8:36 ` Michael S. Tsirkin
2015-10-01 10:59 ` Avi Kivity
2015-10-01 10:59 ` [dpdk-dev] " Avi Kivity
2015-10-01 14:57 ` Stephen Hemminger
2015-10-01 19:48 ` Alexander Duyck
2015-10-01 19:48 ` [dpdk-dev] " Alexander Duyck
2015-10-01 22:00 ` Stephen Hemminger
2015-10-01 22:00 ` [dpdk-dev] " Stephen Hemminger
2015-10-01 23:03 ` Alexander Duyck
2015-10-01 23:03 ` [dpdk-dev] " Alexander Duyck
2015-10-01 23:39 ` Stephen Hemminger
2015-10-01 23:39 ` [dpdk-dev] " Stephen Hemminger
2015-10-01 23:43 ` Alexander Duyck
2015-10-02 0:04 ` Stephen Hemminger
2015-10-02 0:04 ` [dpdk-dev] " Stephen Hemminger
2015-10-02 1:39 ` Alexander Duyck
2015-10-04 16:49 ` Vlad Zolotarov
2015-10-04 16:49 ` [dpdk-dev] " Vlad Zolotarov
2015-10-04 19:03 ` Greg KH
2015-10-04 20:49 ` Vlad Zolotarov
2015-10-04 20:49 ` [dpdk-dev] " Vlad Zolotarov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2696552.dQRxzH79dc@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=avi@scylladb.com \
--cc=dev@dpdk.org \
--cc=gregkh@linux-foundation.org \
--cc=hjk@hansjkoch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.