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  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:	Fri, 04 Jul 2008 15:37:36 +0100
From:	David Woodhouse <>
To:	Theodore Tso <>
Cc:	Jeff Garzik <>, Andi Kleen <>,
	David Miller <>,,,,,,,
Subject: Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

On Fri, 2008-07-04 at 10:30 -0400, Theodore Tso wrote:
> HOWEVER, as I mentioned in another message, it looks like not all
> forms of mkinitd and/or mkinitramfs scripts deal with /lib/firmware
> correctly, including the one used by the latest version of Ubuntu.
> That to me is a strong argument for either (a) leaving drivers the way
> they are now, or (b) making the new request_firmware() framework be
> able to place the firemware in either the original driver module, or
> in another tg3_firmware.ko module --- which could be unloaded
> afterwards, if people really cared about the non-swappable kernel
> memory being used up.)

Yeah. I had checked that Ubuntu and Fedora _do_ cope with including
firmware in the kernel, but wasn't expecting that Ubuntu would then go
screw it up.

As I said, it's not _impossible_ to include firmware directly in the
module itself; it should just be a case of adding an additional section
like it was in the kernel too, and handling some lifetime issues.

If Ubuntu (and SuSE) are currently shipping broken initramfs tools, then
that may tip the balance from that being unnecessary complexity to
something we should probably do for the short term. Even though they're
_already_ broken, and we're only really taking it from "broken for 70
drivers in initramfs" to "broken for 90 drivers in initramfs". Or
whatever the numbers are. Admittedly I just made those ones up.

> And this is where we pay the price for not having a standard initrd
> generation (with appropriate hooks so that distros could drop in their
> own enhancements) as part of the kernel build process.  If we did, it
> would be a lot easier to make sure all distro's learn about new
> requirements that we have imposed on the initrd.  Because we haven't,
> initrd's are effectively part of the "exported interface" where we
> have to move slowly enough so that distro's can catch up depending on
> their release schedule.  (It also makes it much harder to run a
> bleeding-edge kernel on a release distro system, at least without
> tieing our hands with respect to changes involving the initrd.)

Yeah, you're probably right.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists