linux-kernel - [PATCH v5 1/5] firmware: document user mode helper lock usage

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:   Fri,  9 Sep 2016 14:12:20 +0200
From:   Daniel Wagner <wagi@...om.org>
To:     linux-kernel@...r.kernel.org
Cc:     Ming Lei <ming.lei@...onical.com>,
        "Luis R . Rodriguez" <mcgrof@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Srivatsa S . Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
        "Rafael J . Wysocki" <rjw@...k.pl>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Takashi Iwai <tiwai@...e.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        Daniel Wagner <daniel.wagner@...-carit.de>
Subject: [PATCH v5 1/5] firmware: document user mode helper lock usage

From: Daniel Wagner <daniel.wagner@...-carit.de>

The lock is also used to generate warnings when a direct
firmware load is requested too early.

The usermodehelper locking code was added by b298d289c792 ("PM / Sleep:
Fix freezer failures due to racy usermodehelper_is_disabled()").

As Luis points out:

"Reviewing commit 247bc03742545 ("PM / Sleep: Mitigate race between the freezer
and request_firmware()") which originally extended umh state machine from
just being enabled/disabled, with the concepts of UMH_ENABLED, UMH_FREEZING,
UMH_DISABLED -- its goal was to prevent UMH uses during suspend. So -- the
"UMH lock" on firmware was actually added to help avoid races between freezing
and request_firmware(). We should not re-use UMH status notifiers when the
firmware UMH is disabled for the same concepts -- if we needed such a concept
then we should take this out from UMH code and generalize it."

After some discussion with Ming it was decided to put a comment to the
code to document the usage of the umh and a TODO to resolve this by
having some generic means to detect ongoing freezing operations.

Cc: Ming Lei <ming.lei@...onical.com>
Cc: Luis R. Rodriguez <mcgrof@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Signed-off-by: Daniel Wagner <daniel.wagner@...-carit.de>
---
 drivers/base/firmware_class.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 960f8f7..8eba1fb 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1150,6 +1150,19 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
 	if (ret <= 0) /* error or already assigned */
 		goto out;

+	/*
+	 * The usermode helper lock is taken to serialize the firmware
+	 * loading even when no usermoder mode helper is used at all.
+	 *
+	 * Some drivers may not benefit from firmware loading cache
+	 * when requesting loading in .resume(). In the situation of
+	 * suspend vs. resume, it is still too early for direct
+	 * loading. With UMH lock, we can get a warning or avoid the
+	 * issue.
+	 *
+	 * TODO: Taking the UMH lock is a bit missleading and it makes
+	 * sense to generalize this to a common freezer check.
+	 */
 	ret = 0;
 	timeout = firmware_loading_timeout();
 	if (opt_flags & FW_OPT_NOWAIT) {
-- 
2.7.4