linux-kernel - Re: [PATCH RFC] UIO: Pass information about ioports to userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081125041116.GC17033@suse.de>
Date:	Mon, 24 Nov 2008 20:11:16 -0800
From:	Greg KH <gregkh@...e.de>
To:	"Hans J. Koch" <hjk@...utronix.de>
Cc:	linux-kernel@...r.kernel.org, Mike Frysinger <vapier@...too.org>,
	John Ogness <jogness@...utronix.de>,
	Benedikt Spranger <b.spranger@...utronix.de>
Subject: Re: [PATCH RFC] UIO: Pass information about ioports to userspace

On Mon, Nov 24, 2008 at 11:19:15AM +0100, Hans J. Koch wrote:
> On Sun, Nov 23, 2008 at 05:40:54PM -0800, Greg KH wrote:
> > On Sun, Nov 23, 2008 at 01:14:20PM +0100, Hans J. Koch wrote:
> > > Devices sometimes have memory where all or parts of it can not be mapped to
> > > userspace. But it might still be possible to access this memory from
> > > userspace by other means. An example are PCI cards that advertise not only
> > > mappable memory but also ioport ranges. On x86 architectures, these can be
> > > accessed with ioperm, iopl, inb, outb, and friends. Mike Frysinger (CCed)
> > > reported a similar problem on Blackfin arch where it doesn't seem to be easy
> > > to mmap non-cached memory but it can still be accessed from userspace.
> > > 
> > > This patch allows kernel drivers to pass information about such ports to
> > > userspace. Similar to the existing mem[] array, it adds a port[] array to
> > > struct uio_info. Each port range is described by start, size, and porttype.
> > > 
> > > If a driver fills in at least one such port range, the UIO core will simply
> > > pass this information to userspace by creating a new directory "portio"
> > > underneath /sys/class/uio/uioN/. Similar to the "mem" directory, it will
> > > contain a subdirectory (portX) for each port range given.
> > 
> > This is good, but it would really be nice to provide a way for userspace
> > to access individual ports without having to have access to all ports in
> > the system.  Lots of times we don't want to give root privileges to some
> > programs that only need to read and write simple data to a single
> > device.
> 
> Yes, of course, that'd be nice. But it's very much arch dependent. For
> example, these x86 ioports need special handling on x86, but you can simply
> mmap them on powerpc. Port-like memory ranges on other archs might require
> something completely different.
> Yes, some generic port access layer would really be good, but I'm not sure
> if the UIO core is the right place to implement it. Do you already have a
> solution in mind?

No I don't, sorry, it's just come up a few times recently and I was
hoping that you would have something :)

> Maybe we can look at that in a second step. ATM I just want to avoid these
> situations where userspace needs ugly tricks to find out which ioports
> belong to a certain card.

Agreed, I'm not saying that this patch is not ok at all, sorry if you
misinterpreted it that way.  I have no objection to this patch, as long
as it includes the needed documentation.

thanks,

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