linux-kernel - Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

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:	Tue, 15 Jul 2008 03:21:51 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Woodhouse <dwmw2@...radead.org>,
	alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org
Subject: Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel,
 use it in more drivers.

Linus Torvalds wrote:
> 
> On Mon, 14 Jul 2008, Jeff Garzik wrote:
>> Do you really think embedded system and micro distro authors are in 100%
>> agreement that /lib/firmware is best for their situation?  Really?
> 
> Umm. Why are you bringing up these total red herrings?
> 
> Those embedded systems can just build everything into one image, and are 
> much better off using no modules at all.

Oh come on, embedded systems use modules all the time, and surely you 
know that.  My router running OpenWRT says

	root@gw:~# ipkg list | grep -c kmod
	91

Therefore, simple kernel replacement can create a regression by doing

1) build 2.6.26 kernel, including all associated kernel module packages 
("kmod-*")
2) install new kernel and associated kmod packages
3) watch system work as expected
4) build 2.6.27 kernel, including all associated kernel module packages
5) install new kernel and associated kmod packages
6) watch system fail

Why fail?  The package file lists for kmod-* ipkg's are unaware of any 
firmware needs newly added in 2.6.27.

So the driver gets packaged, but ipkg build process is completely 
unaware of the additional firmware requirement until a manifest is 
updated.  The normal build process appears to succeed -- yet at next 
boot you see that it failed.

Similar breakage for driver disks.

Similar breakage for older versions of mainstream distros (won't get 
copied into initrd, with obvious results).

> But how about instead of complaining, help add the infrastructure then, so 
> that you can insert those firmware things into modules and still use just 
> one single interface? 
> 
> Move _forward_, not backwards.

Does that mean you agree it's a regression?  :)  Sure, I'd be happy to 
help fix the damage.

I am still surprised this was merged at all in its state, and am a bit 
disappointed.  This one

* removed choice, by removing ability to build firmware into modules

* forced a flag day build process change upon all distros/builders who 
switch to >= 2.6.27.  no build script updates == non-working drivers.

* the legal subtext of these changes was not mentioned at all

Generally, we don't do that.  Generally, we give distros the ability to 
choose between old-way and new-way during a time of transition. 
Generally we make it easy for newer kernels to work on existing systems, 
maximizing the [test] audience.

	Jeff

--
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/