linux-kernel - Re: Incorrect uses of get_driver()/put

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: <20120109182045.GG15083@core.coreip.homeip.net>
Date:	Mon, 9 Jan 2012 10:20:45 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Joerg Roedel <joerg.roedel@....com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Michael Buesch <m@...s.ch>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Incorrect uses of get_driver()/put_driver()

On Mon, Jan 09, 2012 at 12:48:36PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 09, 2012 at 12:35:09PM -0500, Alan Stern wrote:
> > The get_driver() and put_driver() routines in the device core are not
> > documented well, and what they really do is quite different from what
> > people might think they do.  In particular, get_driver() does not
> > prevent a driver from being unregistered or unloaded -- the API which 
> > comes closest to doing that is try_module_get().
> > 
> > In fact, get_driver() and put_driver() are pretty much useless for
> > normal purposes, and Dmitry and I have been discussing getting rid of
> > them entirely.  But first we need to make sure that doing so won't mess
> > anything up.
> > 
> > The purpose of this email is to check with the maintainers of the
> > various drivers that seem to be using these routines in questionable
> > ways, to make sure nothing will go wrong.  Here are the places we have 
> > identified:
> > 
> > lib/dma-debug.c:173:  drv = get_driver(dev->driver);
> > lib/dma-debug.c:188:  put_driver(drv);
> > 
> > Joerg, these calls don't seem to do anything, as far as I can tell.  
> > Is there any reason to keep them?
> > 
> > drivers/pci/xen-pcifront.c:596:       if (get_driver(&pdrv->driver)) {
> > drivers/pci/xen-pcifront.c:626:               put_driver(&pdrv->driver);
> > 
> > Konrad, these calls don't seem to do anything either.
> > 
> 
> Looks like they should be replaced with the try_module_get() equivalant
> for the 'struct pci_driver'? Is there such one?

You seem to need stronger guarantees that the driver simply present in
memory. You need to make sure that the driver you fetched is kept being
bound to the device for entire duration of pcifront_common_process().

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