linux-kernel - firmware loading vs. initrd

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

Date:	Thu, 11 Mar 2010 14:39:34 -0800
From:	Johannes Berg <johannes@...solutions.net>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Tomas Winkler <tomasw@...il.com>,
	Kay Sievers <kay.sievers@...y.org>, Greg KH <greg@...ah.com>,
	David Woodhouse <dwmw2@...radead.org>
Subject: firmware loading vs. initrd

Hi,

We recently converted a few wireless drivers to use
request_firmware_nowait() in order to be able to load firmware from
probe. We would like to continue with that so we can load the firmware
before registering with any other subsystems, as we had discussed at the
wireless summit last year.

However, in actually trying this today, I noticed that there's a problem
with this. I made my drivers all built in, and then I ended up with it
not working because the firmware agent that was in my initrd was telling
[1], and the kernel that the firmware could not be found.

I thought of modifying the firmware agent in the initrd to not tell the
kernel it doesn't have it, but that is problematic when using
request_firmware(), the kernel boot will be delayed until the timeout
(one minute).

This can be solved by adding an environment variable to the uevent that
tells userspace whether or not this is coming from request_firmware() or
request_firmware_nowait(). I will follow up with a patch doing that.

Additionally, however, we need to make a change like below to the
firmware agent in order to not reply to asynchronous firmware loads
during the initrd stage. I'm not sure how to actually check that we're
running in an initrd (is that possible?) nor did I actually verify that
the NOWAIT environment variable is set properly.

Thoughts? It seems like this would solve our problems nicely if we can
determine whether we're in the initrd or not.

johannes

--- /lib/udev/firmware.agent	2010-02-18 16:40:39.000000000 -0800
+++ firmware.agent	2010-03-11 12:00:40.000000000 -0800
@@ -21,6 +21,16 @@
     exit 0
 done

+if [ "$NOWAIT" = "1" ] && [ INITRD? ] ; then
+	# Leave the request open in case we are
+	# running from initrd -- we'll deal with
+	# it when we process things again after
+	# the root filesystem is mounted.
+
+	# exit 1 instead?
+	exit 0
+fi
+
 # the firmware was not found
 echo -1 > /sys/$DEVPATH/loading

--
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/