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
| ||
|
Date: Wed, 26 Nov 2008 00:56:48 +0100 From: "Hans J. Koch" <hjk@...utronix.de> To: Greg KH <gregkh@...e.de> Cc: "Hans J. Koch" <hjk@...utronix.de>, 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 08:11:16PM -0800, Greg KH wrote: > 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 :) No such luck :) But I'll think about it... > > > 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 didn't ;-) > I have no objection to this patch, as long > as it includes the needed documentation. Agreed. And I found another flaw. I think that the porttype attribute should not be an int. A string constant would be much better, what do you think? I think I'll come up with a second version soon, a new patch and another one with the documentation. Thanks, Hans -- 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/
Powered by blists - more mailing lists