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 22:52:19 +0100
From:	Marek Vasut <marek.vasut@...il.com>
To:	Jack Stone <jwjstone@...tmail.fm>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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:23, Linus Torvalds wrote:
> > On Mon, Jan 2, 2012 at 1:09 PM, Jack Stone <jwjstone@...tmail.fm> wrote:
> >> 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.
> > 
> > I'd hope that the generic driver just expose enough interfaces that
> > you could basically do a "firmware-load" driver that just loads the
> > firmware and then attaches the device to the generic driver.
> 
> Sounds workable.
> 
> To make the firmware caching easier I would propose one extra function
> in addition to the aforemensioned get_firmware / put_firmware - a
> find_firmware function to search the cache and return the appropriate
> firmware blob. It should only be called if the caller already has a
> refcount to the firmware, it's only use is to save every driver saving a
> pointer to the firmware.
> 
> If noone beats me to it I will try and put together an RFC for a new
> version.

The problem is on systems with limited resources, most notably RAM. If you plug 
in many devices at once, many firmwares will be cached at one point, efectivelly 
doing DoS attach on the machine?

Also, how will this solve the suspect-resume issue? What if the device suspends 
only occasionally -- like every 24 hours -- then you'd have the FW cached all 
the time too?

M
> 
> Thanks,
> 
> Jack
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/