From: "Hans J. Koch" <hjk@hansjkoch.de>
To: Dominic Eschweiler <eschweiler@fias.uni-frankfurt.de>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Hans J. Koch" <hjk@hansjkoch.de>,
Andreas Schallenberg <embedded@gmx.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kvm@vger.kernel.org
Subject: Re: UIO: missing resource mapping
Date: Mon, 16 Jul 2012 23:58:23 +0200 [thread overview]
Message-ID: <20120716215823.GA7879@local> (raw)
In-Reply-To: <1342462572.17531.18.camel@blech>
On Mon, Jul 16, 2012 at 08:16:12PM +0200, Dominic Eschweiler wrote:
> Am Freitag, den 13.07.2012, 21:19 +0300 schrieb Michael S. Tsirkin:
> >
> > UIO has the same property, doesn't it? Multiple users can
> > access device memory through sysfs.
>
>
> Indeed, that's a similar problem. I haven't tried it (yet), but this
> particular problem can maybe circumvented by using mmap with the
> MAP_PRIVATE flag. Doing so is the responsibility of the driver
> programmer (like Hans already said). Even if that mmap trick does not
> work, it is pretty much sure that a BAR is already used by another
> program, if a related kernel driver is loaded. In that case the kernel
> has a chance to avoid such BAR race conditions by not giving the
> possibility to map them to the userspace.
Don't make it more complicated than it is. I see no general problem in
mapping BARs in uio_pci_generic like in any other UIO PCI driver.
>
> Nevertheless, I'm pretty sure that the possibility via sysfs to access
> BARs, which are already managed by a kernel driver, opens the door for
> denial of service attacks.
There are also a few other possible attack scenarios, depending on the
hardware.
That's a general problem of all userspace drivers (e.g. X graphics drivers).
You have to make sure access rights are correct. Making a UIO device node
available to all normal users is foolishly dangerous.
>
> On the other hand, I'm quite a newbie on this topic and maybe I don't
> see the big picture here. Therefore it is up to you guys to make the
> right decision (if needed).
Try to hack up a patch to add generic BAR mapping to uio_pci_generic.c
and post it for review.
Thanks,
Hans
next prev parent reply other threads:[~2012-07-16 21:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4FFE7C1F.7080702@gmx.net>
2012-07-12 19:44 ` UIO: missing resource mapping Hans J. Koch
2012-07-12 23:16 ` Michael S. Tsirkin
2012-07-12 23:40 ` Hans J. Koch
2012-07-12 23:58 ` Michael S. Tsirkin
2012-07-13 8:09 ` Dominic Eschweiler
2012-07-13 13:22 ` Michael S. Tsirkin
2012-07-13 14:18 ` Hans J. Koch
2012-07-13 14:44 ` Dominic Eschweiler
2012-07-13 14:42 ` Dominic Eschweiler
2012-07-13 18:19 ` Michael S. Tsirkin
2012-07-16 18:16 ` Dominic Eschweiler
2012-07-16 21:58 ` Hans J. Koch [this message]
2012-07-18 10:40 ` Dominic Eschweiler
2012-07-18 23:47 ` Hans J. Koch
2012-08-06 11:49 ` Dominic Eschweiler
2012-08-08 22:08 ` Hans J. Koch
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=20120716215823.GA7879@local \
--to=hjk@hansjkoch.de \
--cc=embedded@gmx.net \
--cc=eschweiler@fias.uni-frankfurt.de \
--cc=gregkh@linuxfoundation.org \
--cc=kvm@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).