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]

Date:	Mon, 2 Jan 2012 21:45:58 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Matthew Garrett <mjg@...hat.com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jack Stone <jwjstone@...tmail.fm>,
	Oliver Neukum <oliver@...kum.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 Mon, 2 Jan 2012, Matthew Garrett wrote:

> It's not theoretical hardware. This appears to be the current behaviour 
> of the isight devices. If you reboot they retain their firmware. If you 
> suspend, they don't. So if we have a flow like this:
> 
> 1) user boots from cold. Device comes up with generic USB ID.
> 2) isight_firmware loads and binds. Firmware is loaded. Device 
> disconnects and reconnects with an ID that's bound by the UVC driver.
> 3) user reboots. Device comes up with UVC ID. isight_firmware doesn't 
> bind.
> 4) user suspends.
> 5) user resumes. isight_firmware binds and attempts to load firmware.

Wait a second.  Why does isight_firmware bind at this time?  Binding to
new devices is handled by khubd, which doesn't start running again
until after the resume is finished (the device appears to be new
because its descriptors have changed).  At that point there should be
no trouble reloading the firmware.

> then just caching the firmware is inadequate - we had never previously 
> seen the device on this boot, so we've never loaded it in order to cache 
> it. isight_firmware could unconditionally load the firmware on module 
> load just in case a device is plugged in, but that seems even less 
> elegant than caching it.
> 
> Now this is obviously somewhat mitigated because isight_firmware won't 
> have been autoloaded at (3), so won't be there at (5) unless the user's 
> manually loaded it. But insmodding a driver shouldn't result in stuff 
> breaking later.

I don't see how this matters very much.  Certainly not enough to
justify all the effort put into this email thread already.

Regardless of what isight_firmware does, the original UVC device 
instance is gone.  The new device instance won't appear until the khubd 
thread starts running again, after the resume is finished.  As far as 
userspace is concerned, that's all that matters.

Even in situations where isight_firmware does somehow manage to bind
during resume, the only question is how it can avoid hanging or
delaying the resume procedure.  Doing an async firmware load will solve
that.

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/