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

> > The USB suspend/resume function does that "unbind/rebind" dance, and
> > that causes a "device_attach()". Which causes a probe() to be called.
> > 
> > Should it do that? I think not, not if the ID's haven't changed. But I
> > don't know the USB layer all that well.
> 
> The ID has changed. That is why we run into this problem.
> And indeed the USB layer does the rebind only if either
> 
> a) ID has changed

That's not true, or at least, it shouldn't be true.

If the ID has changed then there's nothing to rebind.  The old device
is gone; it cannot be resumed or rebound at all.  That's the theory,
and indeed things really do work that way during reset-resume.

Now, during an ordinary resume, the USB core does not check IDs.  It
assumes that if suspend power was provided to the bus and the device
was connected to the bus the entire time, then the device remains
unchanged.  Perhaps this assumption is a mistake, but so far I haven't
seen any data to prove that it is.

> b) the driver tells us that it cannot deal with a device that has lost its state

This case applies only in situations where the driver doesn't have a 
reset_resume method.  The uvc driver does have one.

(You left out a third case: The driver doesn't have any suspend/resume
methods.  But this case applies only when the device has not lost its
state, and besides, the uvc driver does have these methods.)

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/