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: <CA+55aFwf06vRraVqtz8_2qWjxH0V=Yj5m7mEy3XVbA7+qj5k5A@mail.gmail.com>
Date:	Mon, 2 Jan 2012 12:48:48 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jack Stone <jwjstone@...tmail.fm>
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 Mon, Jan 2, 2012 at 12:41 PM, Jack Stone <jwjstone@...tmail.fm> wrote:
>
> What about the case where the firmware that needs to be loaded is on the
> USB device that needs the firmware. This can be resolved at boot using
> an initrd but at resume time we don't have that.

Quite frankly, caching the firmware will just automagically fix this.

I don't understand why people even bother to talk about USB ID's etc
changing - that is totally irrelevant. We don't look up firmware by
USB ID's anyway.

So the *only* thing you need is:

 - don't have the firmware loaded by some special user space helper -
use "load_firmware()" (which in turn then will use a user-space helper
to load it, but that's a separate issue)

 - make sure "load_firmware()" caches the firmware by firmware name.

You can even make the caching be some simple "cache for at least 10
seconds after the last 'put' operation", and you'll be able to
trivially handle the case of a device "going away" only to be
immediately reconnected due to some electrical issue or whatever
(including changing USB ID's).

Even if the ID's change, the driver should damn well react to the new
ID and load the same damn firmware, because it's the same damn
physical device.

Why are you guys making it any more complicated than that?

Sure, if you have a user-space driver and you load the firmware
magically from user space too, and never use "request_firmware()" in a
real kernel driver, then you can never handle suspend/resume
correctly, BUT WHO THE F*CK CARES? At that point it's a "the kernel
cannot do it, because the kernel has nothing to do with it", but
exactly for the same reason it is TOTALLY POINTLESS to even bring it
up as an issue. It's not an issue - it's a broken user-space driver
that has nothing to do with the kernel, and shouldn't be discussed on
kernel lists as a kernel issue.

So the only thing we need is to fix the braindamaged firmware
interfaces. We need caching, and we need to replace (or at least
extend) "load_firware()" with "[get|put]_firmware()".

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