linux-kernel - [PATCH v3] firmware: log name & outcome of loaded firmware

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: <20191117234734.27101-1-robbat2@gentoo.org>
Date:   Sun, 17 Nov 2019 15:47:34 -0800
From:   "Robin H. Johnson" <robbat2@...too.org>
To:     mcgrof@...nel.org
Cc:     linux-kernel@...r.kernel.org, sir@...wn.com,
        ~sircmpwn/public-inbox@...ts.sr.ht, gregkh@...uxfoundation.org,
        rafael@...nel.org, "Robin H. Johnson" <robbat2@...too.org>
Subject: [PATCH v3] firmware: log name & outcome of loaded firmware

It's non-trivial to figure out names of firmware that was actually
loaded, add a debug statement at the end of _request_firmware that logs
the name & result of each firmware.

This is esp. valuable early in boot, before logging of UEVENT is
available.

v3:
- Log at dev_dbg level per maintainer.
- HOWTO: Enable at boot via kernel boot param
  dyndbg="func _request_firmware +p"
- Credit to Drew DeVault for parallel creation and help promoting the
  idea.

Alternate-Creation: Drew DeVault <sir@...wn.com>
Signed-off-by: Robin H. Johnson <robbat2@...too.org>
---
 drivers/base/firmware_loader/main.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index bf44c79beae9..84a879608ca4 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -791,6 +791,13 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
 		fw = NULL;
 	}
 
+	/* Provide a consistent way to capture the result of trying to load any
+	 * firmware. As a potential future improvement, this might include
+	 * persistent state that firmware is loaded (or failed to load for some
+	 * reason). See Message-ID: <20191113205010.GY11244@...do-not-panic.com>
+	 * for background */
+	dev_dbg(device, "%s %s ret=%d\n", __func__, name, ret);
+
 	*firmware_p = fw;
 	return ret;
 }
-- 
2.24.0