linux-kernel - Re: UIO: missing resource mapping

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: <20120716215823.GA7879@local>
Date:	Mon, 16 Jul 2012 23:58:23 +0200
From:	"Hans J. Koch" <hjk@...sjkoch.de>
To:	Dominic Eschweiler <eschweiler@...s.uni-frankfurt.de>
Cc:	"Michael S. Tsirkin" <mst@...hat.com>,
	"Hans J. Koch" <hjk@...sjkoch.de>,
	Andreas Schallenberg <embedded@....net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	kvm@...r.kernel.org
Subject: Re: UIO: missing resource mapping

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
--
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/