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, 02 Jan 2012 21:09:08 +0000
From:	Jack Stone <jwjstone@...tmail.fm>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Alan Stern <stern@...land.harvard.edu>,
	Oliver Neukum <oliver@...kum.org>,
	Matthew Garrett <mjg@...hat.com>,
	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 02/01/12 21:00, Linus Torvalds wrote:
> On Mon, Jan 2, 2012 at 12:55 PM, Jack Stone <jwjstone@...tmail.fm> wrote:
>>
>> The problem comes with knowing when to put the firmware - how do we tell
>> the generic driver that that device has firmware that might need to be
>> freed on disconnect. I don't know enough about USB to know if we can
>> tell if the same device has reconnected due to firmware being loaded or
>> if it was simply unplugged and a new device plugged in.
> 
> Well, if we just have a 10-second timeout for the firmware flushing
> after the last "put" operation, we don't even care.
> 
> It doesn't even *matter* if the device is a physically different
> device - if the driver loads the same firmware, it will be cached, and
> it will still be correct for that (physically different, but with the
> same firmware requirements) device. So even the whole "user switched
> devices around" issue is irrelevant.
> 
> Of course, if the driver is some piece-of-crap that explicitly loads
> the wrong firmware for the device it manages, the firmware will be
> wrong, but hey, "Don't do that then". The drivers job very much
> includes being able to look at the device ID (whether USB or PCIe or
> PCMCIA) and figure out which firmware image it needs to load.

What about USB "class" drivers e.g. usb-storage. They handle any device
that reports itself as a usb mass storage device. There could be a
device that needs to be bootstrapped before it becomes a generic usb
mass storage device. Do we really want to have to write a new driver
that is almost identical to the generic driver but handles the USB
firmware correctly.

The other option is to extend the class drivers to understand that a
certain device needs this piece of firmware and to handle it but that
will bloat the generic drivers with lots of vendor stuff. We could do
this by lists of USB ids or something similar.

Thanks,

Jack

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