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]
Message-ID: <20080704235839.GA5649@khazad-dum.debian.net>
Date:	Fri, 4 Jul 2008 20:58:39 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Olivier Galibert <galibert@...ox.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Hannes Reinecke <hare@...e.de>, Takashi Iwai <tiwai@...e.de>,
	Theodore Tso <tytso@....edu>, Jeff Garzik <jeff@...zik.org>,
	Andi Kleen <andi@...stfloor.org>,
	David Miller <davem@...emloft.net>, hugh@...itas.com,
	akpm@...ux-foundation.org, kosaki.motohiro@...fujitsu.com,
	mchan@...adcom.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, netdev@...r.kernel.org
Subject: Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

On Sat, 05 Jul 2008, Olivier Galibert wrote:
> On Fri, Jul 04, 2008 at 03:42:37PM +0100, David Woodhouse wrote:
> > It doesn't yet; that patch is in linux-next. The firmware is shipped as
> > part of the kernel source tree, and you currently need to run 'make
> > firmware_install' to put it in /lib/firmware, although we're looking at
> > making that easier because apparently having to run 'make
> > firmware_install' is too hard...
> 
> Won't that break multiple kernel installs on any binary packaging
> system that cares about file collisions?  Multiple kernel rpms
> providing the same /lib/firmware files would break things wouldn't
> they ?

Correct.

We will probably need per-kernel directories, exactly like what is done for
modules.  And since there are (now) both kernel-version-specific, and
non-kernel-version-specific firmware, this means the firmware loader should
look first on the version-specific directory (say, /lib/firmware/$(uname
-r)/), then if not found, on the general directory (/lib/firmware).

Nothing too dificult to pull off, but something that needs to be done before
this entire thing gets deployed on unsuspecting users.  It is bad enough
that it created such a commotion when deployed on unsuspecting developers...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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