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]
Date:	Mon, 8 Dec 2014 22:08:56 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
Cc:	Marcel Holtmann <marcel@...tmann.org>,
	Ming Lei <ming.lei@...onical.com>, Pavel Machek <pavel@....cz>,
	"John W. Linville" <linville@...driver.com>,
	Grazvydas Ignotas <notasas@...il.com>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Kalle Valo <kvalo@...rom.com>,
	Sebastian Reichel <sre@...g0.de>,
	David Gnedt <david.gnedt@...izone.at>
Subject: Re: wl1251: NVS firmware data

On Monday 08 December 2014 22:00:18 Greg Kroah-Hartman wrote:
> On Mon, Dec 08, 2014 at 08:15:18PM +0100, Pali Rohár wrote:
> > On Nokia N900 NVS data are generated on-the-fly from some
> > bytes from CAL (/dev/mtd1), from state of cellular network
> > and from some other regulation settings.
> 
> When is this "generated"?  At boot time?  Or by the firmware
> loader program you have hooked into being called by the
> kernel at "load the firmware now please" call time?
> 

When userspace system network daemon is started.

> > So I think that files stored in linux-firmware.git tree
> > (which are also installed into /lib/firmware/) should be
> > loaded with request_firmware function. Or not? Do you think
> > something else? What other developers think?
> > 
> > I'm against kernel driver for CAL (/dev/mtd1) for more
> > reasons:
> > 
> > 1) we have userspace open source code, but licensed under
> > GPLv3. And until kernel change license, we cannot include
> > it.
> 
> You can change the license of your code if you want to, don't
> make this type of nonsense argument.
> 

Code is not mine, so I cannot change license.

> > 2) NVS data are (probably) not in one place, plus they
> > depends on something other.
> 
> What is "something other"?  Where are they located?  Why would
> the firmware interface know or care anything about this?
> 

fcc bit and some other data retrieved from daemon which 
communicating with cellular modem.

> > 3) If manufacture XYZ create new device with its own storage
> > format of calibration data this means that correct solution
> > for XYZ is also to implement new kernel fs driver for its
> > own format.
> 
> Yes, as it is doing it's own custom thing, why overload an
> existing interface to do something it was never designed to
> do?
> 
> > Do you really want to have in kernel all those drivers for
> > all different (proprietary) storage formats?
> 
> Yes, we are not afraid of lots of different drivers.  That is
> not even a valid argument, you know better than this :)
> 
> > 4) It does not help us with existence of generic file
> > /lib/firmware/ti-connectivity/wl1251-nvs.bin which comes
> > from linux-firmware.git tree.
> 
> Again, not an issue.  If you don't want that file in the repo,
> ask for it to be removed, and it will be, just send a patch
> to do it.
> 
> greg k-h

-- 
Pali Rohár
pali.rohar@...il.com

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ