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:	Thu, 11 Sep 2008 03:15:12 -0400
From:	Jeff Mahoney <jeffm@...e.com>
To:	Faidon Liambotis <paravoid@...ian.org>
Cc:	David Miller <davem@...emloft.net>, dwmw2@...radead.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org
Subject: Re: [PATCH] firmware: Allow release-specific firmware dir

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Faidon Liambotis wrote:
> David Miller wrote:
>>> Firmware really _isn't_ version-specific.
>> Tell that to every Debian and Debian derived system on the planet.
>>
>> To my knowledge, it is only fedora and possibly one or two other dists
>> that put the firmware files in a unary /lib/firmware location, rather
>> than a versioned /lib/firmware/$KERNELRELASE one.
> [not speaking on behalf of the project, the kernel team or the
> respective maintainers]
> 
> Apparently and afaik you are misinformed:

Well that's the thing. These are specific firmware packages that exist
outside of those created by the kernel. My original patch wasn't
proposing using /lib/firmware/$KERNELRELEASE for *all* firmware blobs,
just those that are generated and installed by the kernel build process.

The problem occurs when you have multiple versions of the kernel
installed and they all want to put firmware blobs into /lib/firmware.
The firmware blobs created by the kernel aren't versioned liked those in
the examples you've provided, so you end up with a bunch of blobs with
potentially different contents, all with the same names.

I'm not suggesting killing /lib/firmware-located blobs at all. That's
where you look once you discover that /lib/firmware/$KERNELRELEASE
doesn't have the blob you're looking for. That's where firmware packages
like the examples below would still place their files. I see no reason
to change that. If the blobs are versioned so that a particular name
always contains the same contents, that's fine too. What we can't have
is files in the same location with different contents.

In the end, though, Andrew's right. We can't go breaking udev prior to
127 with this.

- -Jeff

> $ dpkg -L firmware-bnx2 (or [1])
> ...
> /lib/firmware/bnx2-06-4.0.5.fw
> /lib/firmware/bnx2-09-4.0.5.fw
> ...
> 
> $ dpkg -L firmware-iwlwifi (or [2])
> ...
> /lib/firmware/iwlwifi-3945-1.ucode
> /lib/firmware/iwlwifi-4965-1.ucode
> /lib/firmware/iwlwifi-4965-2.ucode
> ...
> 
> $ dpkg -L firmware-qlogic (or [3])
> ...
> /lib/firmware/ql2100_fw.bin
> /lib/firmware/ql2200_fw.bin
> /lib/firmware/ql2300_fw.bin
> /lib/firmware/ql2322_fw.bin
> /lib/firmware/ql2400_fw.bin
> /lib/firmware/ql2500_fw.bin
> ...
> 
> etc. for the other firmware packages[4].
> 
> Regards,
> Faidon
> 
> 1: http://packages.debian.org/sid/all/firmware-bnx2/filelist
> 2: http://packages.debian.org/sid/all/firmware-iwlwifi/filelist
> 3: http://packages.debian.org/sid/all/firmware-qlogic/filelist
> 4: http://packages.debian.org/firmware


- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkjIxYAACgkQLPWxlyuTD7LuSgCgmAOte+y8dU1TWODKPNwRnrCK
KO8An1VnOh+KvsfHrgtXZ1H/xSdCYuVL
=3/a7
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ