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.1112312033240.28510-100000@netrider.rowland.org>
Date:	Sat, 31 Dec 2011 21:21:45 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Oliver Neukum <oliver@...kum.org>
cc:	Matthew Garrett <mjg@...hat.com>,
	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, Oliver Neukum wrote:

> Am Samstag, 31. Dezember 2011, 16:33:12 schrieb Alan Stern:
> 
> > 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.  :-(
> 
> We are definitely going through do_unbind_rebind(). But I don't think
> it matters why we got there. We seem to be calling probe() too early.
> And we need to guarantee that a driver can request firmware in probe()
> 
> So something has changed in the resume code path further up.

For at least a year and a half, it has been true that rebinding takes
place during the complete phase of system resume.  Clearly that is too 
early to load firmware.  When do you think we should do it instead?  
And how should we keep track of which interfaces need rebinding?

Alan Stern

P.S.: Oliver, it looks like there's a bunch of dead code in
usb_suspend_interface() and usb_resume_interface().  I don't see how
either one can be executed with a driver that doesn't have both suspend
and resume methods.  Such cases should be filtered out when
usb_suspend() calls do_unbind_rebind().  The only odd thing that can
happen is when a driver doesn't support reset-resume.  Do you agree?

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