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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ