From: Avi Kivity <avi@scylladb.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: dev@dpdk.org, hjk@hansjkoch.de, gregkh@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] uio: new driver to support PCI MSI-X
Date: Tue, 6 Oct 2015 15:15:57 +0300 [thread overview]
Message-ID: <5613BB7D.3060202@scylladb.com> (raw)
In-Reply-To: <20151006083356.3da3defa@uryu.home.lan>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@scylladb.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: dev@dpdk.org, hjk@hansjkoch.de, gregkh@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X
Date: Tue, 6 Oct 2015 15:15:57 +0300 [thread overview]
Message-ID: <5613BB7D.3060202@scylladb.com> (raw)
In-Reply-To: <20151006083356.3da3defa@uryu.home.lan>
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.
next prev parent reply other threads:[~2015-10-06 12:16 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 [this message]
2015-10-06 12:15 ` 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
2015-10-16 17:11 ` [dpdk-dev] " 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=5613BB7D.3060202@scylladb.com \
--to=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 \
--cc=stephen@networkplumber.org \
/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.