linux-kernel - Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

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+55aFxcC=RFzpk0AF68krv6UtazT1cmaQoKgz5+dY9Zzcu4Kg@mail.gmail.com>
Date:	Tue, 25 Aug 2015 13:26:40 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Takashi Iwai <tiwai@...e.de>,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Liam Girdwood <liam.r.girdwood@...el.com>,
	"Jie, Yang" <yang.jie@...el.com>, joonas.lahtinen@...ux.intel.com,
	Tom Gundersen <teg@...m.no>, Ming Lei <ming.lei@...onical.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kay Sievers <kay@...y.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Luis Rodriguez <mcgrof@...not-panic.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: Problems loading firmware using built-in drivers with kernels
 that use initramfs.

On Tue, Aug 25, 2015 at 12:58 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
>
> Either build firmware in the kernel or ramdisk (so it is always
> available), or make sure request_firmware() calls are not in driver's
> probe() paths.

The correct answer is almost always that second one.

Drivers that load firmware in their probe parts are generally doign
things wrong.

It's very occasionally the right thing to do - there are a few pieces
of hardware where just about _everything_ about the device is in the
firmware, and you simply can't even problem them before that, because
you don't know what they *are* before the firmware has been loaded.
The extreme case of that might be something like the base hardware
being an FPGA that has a USB interface, but before the FPGA has been
loaded, it basically has no identity. So there are probably valid
cases in theory for loading firmware at probe time, but pretty much
every single case I've ever actually seen, the probe knows what the
actual hardware is from some identifiable piece, and the actual
firmware loading should be delayed until the piece of hardware is
actually opened.

So the "load firmware in probe routine" happens, and we shouldn't
disallow it, but it should be considered a "last resort" kind of
thing.

In general, things like sound drivers should *not* need to have their
firmware in the initrd, even if you build them into the kernel. A disk
driver? Yes. Maybe the root filesystem is on that disk, and you need
the firmware for the disk driver to load it. But a sound device?
Please just make sure that you load the firmware as late as possible.

                        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/