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

Date:	Sun, 21 Feb 2016 14:01:28 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	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()

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.


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?

	-ss