linux-kernel - Re: [PATCH] firmware: set firmware_buf size in fw_get_filesystem

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

Date:	Sun, 21 Feb 2016 08:46:51 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:	Ming Lei <ming.lei@...onical.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] firmware: set firmware_buf size in
 fw_get_filesystem_firmware()

On Sun, 2016-02-21 at 14:01 +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (02/20/16 22:59), Mimi Zohar wrote:
> > On Sat, 2016-02-20 at 18:22 +0900, Sergey Senozhatsky wrote:
> > > Set firmware_buf->size in fw_get_filesystem_firmware() after
> > > successful kernel_read_file_from_path(), otherwise assign_firmware_buf()
> > > fails.
> > > 
> > > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
> > > ---
> > >  drivers/base/firmware_class.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > > index b8bc846..7cf41a5 100644
> > > --- a/drivers/base/firmware_class.c
> > > +++ b/drivers/base/firmware_class.c
> > > @@ -335,6 +335,7 @@ static int fw_get_filesystem_firmware(struct device *device,
> > >  		}
> > >  		dev_dbg(device, "direct-loading %s\n",
> > >  			buf->fw_id);
> > > +		buf->size = size;
> > >  		fw_finish_direct_load(device, buf);
> > >  		break;
> > >  	}
> > 
> > Thanks, Sergey. 
> > 
> > Somehow this was dropped in v4.
> 
> sure, no prob.
> if there is a way to fold this small fix into the original patch, then I wouldn't
> mind at all to go with this option.

Will do, thanks.
> 
> The other thing is that, the dmesg output has changed, and now it keeps the
> log of unsuccessful ucode accesses from ->ucode_api_max to ->ucode_api_min:
> 
> [    1.236866] Unable to open file: /lib/firmware/updates/4.5.0-rc4-mm1-dbg-00407-g2edf49f-dirty/iwlwifi-7260-17.ucode (-2)
> [    1.236874] iwlwifi 0000:02:00.0: loading /lib/firmware/updates/4.5.0-rc4-mm1-dbg-00407-g2edf49f-dirty/iwlwifi-7260-17.ucode failed with error -2
> [    1.236889] Unable to open file: /lib/firmware/updates/iwlwifi-7260-17.ucode (-2)
> [    1.236894] iwlwifi 0000:02:00.0: loading /lib/firmware/updates/iwlwifi-7260-17.ucode failed with error -2
> [    1.237064] Unable to open file: /lib/firmware/4.5.0-rc4-mm1-dbg-00407-g2edf49f-dirty/iwlwifi-7260-17.ucode (-2)
> [    1.237073] iwlwifi 0000:02:00.0: loading /lib/firmware/4.5.0-rc4-mm1-dbg-00407-g2edf49f-dirty/iwlwifi-7260-17.ucode failed with error -2
> [    1.237094] Unable to open file: /lib/firmware/iwlwifi-7260-17.ucode (-2)
> [    1.237099] iwlwifi 0000:02:00.0: loading /lib/firmware/iwlwifi-7260-17.ucode failed with error -2
> [    1.237106] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-7260-17.ucode failed with error -2
> [    1.237190] Unable to open file: /lib/firmware/updates/4.5.0-rc4-mm1-dbg-00407-g2edf49f-dirty/iwlwifi-7260-16.ucode (-2)
> [    1.237195] iwlwifi 0000:02:00.0: loading /lib/firmware/updates/4.5.0-rc4-mm1-dbg-00407-g2edf49f-dirty/iwlwifi-7260-16.ucode failed with error -2
> [    1.237201] Unable to open file: /lib/firmware/updates/iwlwifi-7260-16.ucode (-2)
> [    1.237204] iwlwifi 0000:02:00.0: loading /lib/firmware/updates/iwlwifi-7260-16.ucode failed with error -2
> [    1.237217] Unable to open file: /lib/firmware/4.5.0-rc4-mm1-dbg-00407-g2edf49f-dirty/iwlwifi-7260-16.ucode (-2)
> [    1.237221] iwlwifi 0000:02:00.0: loading /lib/firmware/4.5.0-rc4-mm1-dbg-00407-g2edf49f-dirty/iwlwifi-7260-16.ucode failed with error -2
> 
> 
> is this intentional? is there any reason to give this info back to user or
> this is just a small regression?

Thank you for pointing this out.  The  move from
kernel_read_file_from_fd() to kernel_read_from_path() introduced this
change.  Neither function should display errors.

Mimi