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] [day] [month] [year] [list]

Date:	Sat, 31 Dec 2011 12:26:57 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	drahemmaps@....net, davej@...hat.com, linux-kernel@...r.kernel.org,
	gregkh@...e.de, linux-usb@...r.kernel.org
Subject: Re: loading firmware while usermodehelper disabled.

On Sat, Dec 31, 2011 at 12:15 PM, Matthew Garrett <mjg@...hat.com> wrote:
> On Sat, Dec 31, 2011 at 11:29:56AM -0800, Linus Torvalds wrote:
>
>> But what the driver *should* be doing is to load the firmware at
>> device open time (NOT at "driver load time" - because that can and
>> does happen too early too, for the case of built-in drivers!) and
>> simply keep the firmware around in the case of a suspend/resume event,
>> so that it doesn't have to re-load it off a disk (or network, or
>> whatever) that hasn't been resumed yet!
>
> That doesn't work for the isight firmware loader - there's nothing for
> userspace to open until the device has had the firmware loaded, at which
> point it detaches and reattaches as a UVC device. The code could be
> merged into the UVC driver and a fake v4l device exposed, but even then
> you'd still need to deal with the underlying usb_device suddenly
> changing under you.

Well, what you *could* do is to simply say: this driver has to be a
module, and cannot be built-in. Or, if built-in, the firmware has to
be built-in too (but there are probably licensing issues with that).

At that point, you can load the firmware when you load the isight
driver, since hopefully by then you have a real filesystem (not just
initrd or something - although you could obviously put the firmware in
the initrd image too).

And then, you just keep the firmware in memory as long as the module
is loaded. It's not as good as loading at open time, but at least for
the suspend/resume case it's better than trying to load it at resume
time when it fundamentally cannot work.

> So for this specific case, I'd like to track down why the behaviour has
> changed

That driver isn't all that recent, it may be that what changed is that
you just used to rely on the disk being woken up before the isight
device was, and things just magically happened to work.

We explicitly disallowed the "magically happened to work" case because
it was so often not true, and when it wasn't true, it resulted in
60-second timeouts (or whatever the "failed to load" timeout was) and
non-working devices. So the warning and the failure is actually "new"
(well, by now it's been a year or so), to make developers who write
drivers *see* the failure instead of having a "it works on my
particular hardware and filesystem layout" model.

                           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/