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 14:46:56 -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 2:29 PM, Matthew Garrett <mjg@...hat.com> wrote:
>>
>> Why do you make up all these idiotic theoretical cases that nobody
>> cares about and has no relevance what-so-ever for the 99%?
>
> Rebooting is a theoretical case?

Your forcing the issue to be some crazy one that "cannot be solved" is
the theoretical case. I'm telling you that "reloading the firmware at
resume time" is wrong, and trivially solved by loading it before
resume time. You then make up all these invalid arguments about why
it's somehow magically impossible, but you *literally* do it by
refusing to look at what *is* possible.

It's *trivial* to attach the firmware driver and load the firmware
even if the firmware isn't needed - because you know it *will* be
needed if somebody suspends. Why not just do that? Why make up these
horrible problems that are totally irrelevant?

You can match the driver by various things like DMI strings etc, if
you really don't have a USB (or PCI or whatever) ID to match against.
But in fact, almost always you at least have things like subvendor
ID's etc that you *can* match against.

So why are you actively trying to make something complicated that
isn't? Why are you arguing against the simple solution that can easily
be made to work for the odd and unusual case you are trying to push?

                         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/