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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 03 Jan 2012 12:19:16 +0000
From:	Jack Stone <jwjstone@...tmail.fm>
To:	Oliver Neukum <oliver@...kum.org>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alan Stern <stern@...land.harvard.edu>,
	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 03/01/12 11:57, Oliver Neukum wrote:
> Am Dienstag, 3. Januar 2012, 01:42:20 schrieb Alan Cox:
>> In that case however you don't want some generic firmware module knowing
>> all this crap, your driver can just request_firmware() the stuff as
>> modprobe and free it up on the module unload. For a typical 8bit firmware
>> of a few K you'll free a ton more memory unloading the module than the
>> firmware ! That I think actually covers the majority of devices under
>> discussion.
> 
> I am afraid it doesn't, at least not fully.
> We have many devices whose primary (operational) driver does not load
> the firmware. That job is left to a secondary driver or user space.
> 
> We could leave those secondary drivers and their firmware in RAM after
> their primary usage and except for a few pathological cases (which
> can be solved with a few udev rules preventively loading drivers) we'd
> be good, but we lack a mechanism for switching to a seconary driver
> and back during resumption.

You don't mension the bus used so I'm going to use USB as an example.

As I understand it the majority of devices that need firmware have two
different identities: the "bootstrap" id and the "primary" id. If we
always make sure we have the drivers for both bootsrap and primary ids
loaded then we should have the firmware in memory. If the device has
lost its firmware then it will reregister with the bootstrap id
otherwise it will continue with the primary id. Either way the correct
driver should pick it up and handle it.

That said, I guess there are more complicated / difficult pieces of
hardware that might not do that. Is that the case here? Can we detect
that the firmware needs reloading and have the primary driver "yield" to
the firmware driver?

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/