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]

Message-ID: <487D0ED1.7010003@garzik.org>
Date:	Tue, 15 Jul 2008 16:55:45 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Frans Pop <elendil@...net.nl>, arjan@...radead.org,
	akpm@...ux-foundation.org, 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 Tue, 15 Jul 2008, Jeff Garzik wrote:
>> Already posted a list.
> 
> No you didn't.
> 
> You posted a list of problems you have from doing odd and stupid things. 
> Not the reports, not the explanations of what those odd and stupid 
> things actually were in practice, and why they had to be that stupid.
> 
> Quite frankly, I suspect that it's all a matter of "people compiled their 
> own kernels, and didn't copy the new files, because they just didn't 
> realize they needed to".

No, I spelled out a list of projects, what would break, and how it would 
break.

Again,

* Red Hat driver disks.  The build process is unaware of the need to 
bundle firmware.  Any use with Fedora (or, later, RHEL) will result in a 
non-working driver, for the simple reason that firmware is not copied 
onto the image.

* Embedded projects like OpenWRT, that divide up kernel modules into 
multiple packages.  Since it's not just one big package, you have to 
update each package's list of files to include the newly split-out 
firmwares.  Failure to do so results in a successful build set of 
packages... of drivers that lack their firmware.

* Router and embedded system image builders like tomsrtbt, with similar 
problem to RH driver disks:  they simply do not know that a firmware 
needs to be copied into the image, alongside the tg3 driver.

* Older userlands where, axiomatically, the mkinitrd and other firmware 
fixes have not been made, and may never be made.

Yes, it is a matter of education.

Yes, it is a matter of fixes.

That does not change the fact that 2.6.27 will mean non-working drivers 
for these situations, and there is a simple remedy for this entire class 
of problems:  retain ability to compile firmware into the module.

That does not change the fact that useful testers may be turned away 
from 2.6.2[78] while waiting for Red Hat or OpenWRT or whomever to fix 
their stuff.

	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/