linux-kernel - Re: [PATCH V3] drivers/uio/uio_pci_generic.c: allow access for non-privileged processes

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: <20100429195216.GA31637@redhat.com>
Date:	Thu, 29 Apr 2010 22:52:16 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Tom Lyon <pugs@...n-about.com>
Cc:	hjk@...utronix.de, gregkh@...e.de, chrisw@...s-sol.org,
	joro@...tes.org, avi@...hat.com, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3] drivers/uio/uio_pci_generic.c: allow access for
	non-privileged processes

On Thu, Apr 29, 2010 at 12:29:40PM -0700, Tom Lyon wrote:
> Michael, et al - sorry for the delay, but I've been digesting the comments and researching new approaches.
> 
> I think the plan for V4 will be to take things entirely out of the UIO framework, and instead have a driver which supports user mode use of "well-behaved" PCI devices. I would like to use read and write to support access to memory regions, IO regions,  or PCI config space. Config space is a bitch because not everything is safe to read or write, but I've come up with a table driven approach which can be run-time extended for non-compliant devices (under root control) which could then enable non-privileged users. For instance, OHCI 1394 devices use a dword in config space which is not formatted as a PCI capability, root can use sysfs to enable access:
> 	echo <offset> <readbits> <writebits> > /sys/dev/pci/devices/xxxx:xx:xx.x/<yyy>/config_permit
> 
> 
> A "well-behaved" PCI device must have memory BARs >= 4K for mmaping, must have separate memory space for MSI-X that does not need mmaping
> by the user driver, must support the PCI 2.3 interrupt masking, and must not go totally crazy with PCI config space (tg3 is real ugly, e1000 is fine).

e1000 has a good driver in kernel, though.

> 
> Again, my primary usage model is for direct user-level access to network devices, not for virtualization, but I think both will work.

I suspect that without mmap and (to a lesser extent) write-combining,
this would be pretty useless for virtualization.

> So, I will go outside UIO because:
> 1 - it doesn't allow reads and writes to sub-drivers, just irqcontrol
> 2 - it doesn't have ioctls
> 3 - it has its own interrupt model which doesn't use eventfds
> 4 - it's ugly doing the new stuff and maintaining backwards compat.
> 
> I hereby solicit comments on the name and location for the new driver.
--
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/