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 13:27:03 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	Jack Stone <jwjstone@...tmail.fm>,
	Alan Stern <stern@...land.harvard.edu>,
	Oliver Neukum <oliver@...kum.org>,
	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 1:19 PM, Matthew Garrett <mjg@...hat.com> wrote:
> On Mon, Jan 02, 2012 at 12:48:48PM -0800, Linus Torvalds wrote:
>
>> Why are you guys making it any more complicated than that?
>
> Because it's inadequate. You can't guarantee that we ever loaded
> firmware.

If we didn't load the firmware before the suspend, then the resume
function of a device sure as hell had better not load it at resume
time either.

And don't make the stupid argument that we don't know. That's just
inane. Either the driver loads the firmware at startup, or it doesn't.
If it loads it at startup, the firmware will have been loaded. If it
loads it only at "open" time or similar (and the device wasn't
opened), then the resume had better *know* about that, and not try to
load the firmware of a device that wasn't open!

And for chrissake, don't bother making it more complicated than it is,
just for some theoretical hardware or situation that nobody cares
about.

Go back to the original report of the *actual* problems we have. They
are not some complex case where things magically change. The REAL
ACTUAL problems that people have are for very straightforward
situations where we simply do the wrong thing, largely because our
firmware loading is full of crap.

Fix the 99%. Screw the crazy shit, don't even bother worrying about it
until *after* the 99% is fixed.

                            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/