From: Vlad Zolotarov <vladz@cloudius-systems.com>
To: "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 11:23:11 +0300 [thread overview]
Message-ID: <561384EF.8020100@cloudius-systems.com> (raw)
In-Reply-To: <20151006013000-mutt-send-email-mst@redhat.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Vlad Zolotarov <vladz@cloudius-systems.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: hjk@hansjkoch.de, dev@dpdk.org, gregkh@linux-foundation.org,
Stephen Hemminger <stephen@networkplumber.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 11:23:11 +0300 [thread overview]
Message-ID: <561384EF.8020100@cloudius-systems.com> (raw)
In-Reply-To: <20151006013000-mutt-send-email-mst@redhat.com>
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
next prev parent reply other threads:[~2015-10-06 8:23 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
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 [this message]
2015-10-06 8:23 ` 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=561384EF.8020100@cloudius-systems.com \
--to=vladz@cloudius-systems.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.