linux-kernel - Re: loading firmware while usermodehelper disabled.

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: <Pine.LNX.4.44L0.1112311028270.22327-100000@netrider.rowland.org>
Date:	Sat, 31 Dec 2011 10:33:12 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Matthew Garrett <mjg@...hat.com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Larry Finger <Larry.Finger@...inger.net>,
	Chaoming Li <chaoming_li@...lsil.com.cn>,
	"John W. Linville" <linville@...driver.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	USB list <linux-usb@...r.kernel.org>,
	Linux Wireless List <linux-wireless@...r.kernel.org>
Subject: Re: loading firmware while usermodehelper disabled.

On Sat, 31 Dec 2011, Matthew Garrett wrote:

> On Fri, Dec 30, 2011 at 04:22:06PM -0800, Linus Torvalds wrote:
> 
> > It's isight_firmware_load(), in the isight_firmware driver. The driver
> > doesn't actually do anything but load the firmware, and is apparently
> > not very good at that either.
> > 
> > It should either fake a disconnect and reconnect of the device (and
> > let the reconnect then load the firmware through udev or something) or
> > it should just save the firmware image in memory from the original
> > load, and make the resume just re-initialize it - not load it.
> 
> Mm. My recollection is that these devices retained their firmware over 
> suspend/resume, so wouldn't resume with a USB id that matched the driver 
> and so this code shouldn't be called. It seems that either I was 
> horribly wrong about that, or something's changed in the USB layer 
> that's resulting in them resetting themselves. Newer devices don't 
> require this, so I'll need to try to chase up some older hardware to 
> figure out what's going on.

Nothing has changed in the USB layer -- it has always been true that
devices could be reset during a suspend/resume cycle.  This isn't a
matter of how the stack is written or anything like that; some
motherboards simply do not provide suspend power to their USB
controllers.  Or the firmware reinitializes the controllers and
attached devices during resume, forcing Linux's USB core to reset
every device on the affected buses.

When it comes to suspend/resume, there are almost no guarantees.  :-(

Alan Stern

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