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+55aFx2NMDSY8rmsToU-zxe+bR-gzsxc8HajNWNWfykVJqd9w@mail.gmail.com>
Date:	Mon, 2 Jan 2012 13:23:21 -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 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.

So instead of duplicating the driver, or teaching the generic driver
about magic setup stuff, you could do a "specialized" driver for that
particular device (more likely, that manufacturers devices) and then
have some way to hand it over.

Of course, in the end it does matter what the "class" is. For storage
devices, we really do want the kernel to handle things for us
entirely. For other kinds of devices (and the isight camera does come
to mind) I suspect it's entirely fine to just say "whatever, we don't
care enough, just have some udev rules, load things from user space,
and no, you cannot have a videochat active over a suspend/resume
event".

So while I think kernel drivers should generally strive for "you can
suspend/resume without user space even noticing", I do think that it
depends on the particular device just *how* strict you should be about
that rule. Some devices just don't need that kind of attention.

IOW, I think the kernel should *strive* for doing the right thing, and
I think the firmware loader right now makes it unnecessarily hard to
do things right, but at the same time there are no black-and-white
absolute rules. There are always going to be exceptions where somebody
says "this is a crap device, and it's simply not worth worrying
about".

                   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/