linux-kernel - Re: [PATCH v2] firmware loader: log path to loaded firmwares

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: <20191113005628.GT11244@42.do-not-panic.com>
Date:   Wed, 13 Nov 2019 00:56:28 +0000
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Drew DeVault <sir@...wn.com>
Cc:     linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        ~sircmpwn/public-inbox@...ts.sr.ht, robbat2@...too.org
Subject: Re: [PATCH v2] firmware loader: log path to loaded firmwares

On Sun, Nov 03, 2019 at 01:06:46PM -0500, Drew DeVault wrote:
> 
> This is useful for users who are trying to identify the firmwares in use
> on their system.
> 
> Signed-off-by: Drew DeVault <sir@...wn.com>
> ---
> v2 uses dev_dbg instead of printk(KERN_INFO)
> 
>  drivers/base/firmware_loader/main.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
> index bf44c79beae9..2537da43a572 100644
> --- a/drivers/base/firmware_loader/main.c
> +++ b/drivers/base/firmware_loader/main.c
> @@ -504,6 +504,7 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv,
>  					 path);
>  			continue;
>  		}
> +		dev_dbg(device, "Loading firmware from %s\n", path);

Because this is dev_dbg() I'm willing to consider it, so that its not
always enabled. However its not in the right place, the code path you
are addressing is only for direct filesystem lookups. If that fails
some systems do a fallback call out to userspace. To cover both cases,
you want it at the end of _request_firmware() on the success path. Can
you send a new patch?

  Luis

>  		if (decompress) {
>  			dev_dbg(device, "f/w decompressing %s\n",
>  				fw_priv->fw_name);
> -- 
> 2.23.0
>