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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Nov 2019 20:19:07 +0000
From:   "Robin H. Johnson" <robbat2@...too.org>
To:     Luis Chamberlain <mcgrof@...nel.org>
Cc:     Drew DeVault <sir@...wn.com>, 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 Wed, Nov 13, 2019 at 12:56:28AM +0000, Luis Chamberlain wrote:
> 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?
As the author of a separate patch that predates Drew's patch (originally
in July, with a later version sent to the list last week):
https://pastebin.com/Tf09x3ed (v1)
https://lkml.org/lkml/2019/11/7/800 (v2)

This already uses the _request_firmware path to fire after the firmware
was successfully loaded. The commit message is also specific that it's
to cover early boot situations, before UEVENT can be logged.

dev_dbg means that the loglevel must have been set to debug BEFORE the
firmware load took place, but this means either setting system-wide
debug spam or requiring debugfs, which is annoying for boot stuff (not
impossible, just annoying).

I have two uses cases overall:
- log so you know exactly when it's loaded successfully (great if
  loading a firmware causes your system to lock up a few seconds later)
- at some point in the future, being able to query what firmware was
  loaded in the past, and esp. exactly what version/data was in that
  firmware file.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@...too.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Download attachment "signature.asc" of type "application/pgp-signature" (1114 bytes)