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: <487D1327.7090805@garzik.org>
Date:	Tue, 15 Jul 2008 17:14:15 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Theodore Tso <tytso@....edu>, david@...g.hm,
	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 Tue, 15 Jul 2008, Jeff Garzik wrote:
>> Already started, in fact, since Linus said he would not reject it out of
>> hands.
> 
> Btw, I need to see it actually solve a real problem. As it is, I really 
> think you've just painted yourself into a corner where you can't just 
> admit that we can just load the firmware directly.

Kernel 2.6.26.  Older userland w/ initrd requirement, plus module w/ 
compiled-in firmware.

Simply dropping 2.6.27 into that situation will produce an unbootable 
system, since the firmware would not get copied into the initrd.

That's not just a kernel hacker situation.  Plenty of sites, even a few 
large Red Hat deployments, run newer kernels on a known-stable, older 
userland.  RH does not actively support swap-in-your-own-kernel, 
preferring our own tested kernel, but new-kernel/older-userland is not 
uncommon.

With upstream as it is today, there are just too many little ways the 
firmware can fail to follow the driver it once lived inside.  And the 
consequences of failure are delayed (until next boot), silent (until 
next boot), and notable (may produce non-booting system, certainly a 
non-working driver).

	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/