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 12:27:52 -0700
From:	David Woodhouse <dwmw2@...radead.org>
To:	Theodore Tso <tytso@....edu>
Cc:	Jeff Garzik <jeff@...zik.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>, david@...g.hm,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.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.

On Tue, 2008-07-15 at 14:58 -0400, Theodore Tso wrote:
> On Tue, Jul 15, 2008 at 02:44:46PM -0400, Jeff Garzik wrote:
> > All of the regressions examples I am citing are cured by  
> > firmware-in-module, because they are all examples of problems that occur  
> > when you remove the ability to reproduce the same functional pieces as  
> > 2.6.26.
> 
> Jeff,
> 
> 	I think you've said this before, but let me try to help you
> cut to the chase.  You are willing to *implement*
> firmware-in-the-module for request_firmware(), but you want a
> commitment that David Woodhouse and Linus will accept such a patch
> before you go off and write it.  Is that right?

The more important question is whether _Linus_ will take it, and of
course I can't answer for him.

Personally I think it's pointless. But since it's only _mildly_
counterproductive, if you really want to do it then I wouldn't actively
oppose it unless it turns out to be a mess to implement, or unless it's
limited to working only with the in-tree firmware.

If you implement it cleanly and optionally (and defaulting off), and if
it works properly with out-of-tree firmware too (so I can build a
libertas usb8xxx.ko module with the firmware included, for example),
then I certainly wouldn't throw my toys out of the pram over it.
Ideally, it would work for out-of-tree drivers (make M=... modules) too.

I was thinking that we could maybe post-process .ko files (which we do
already for other reasons), and add a special section in them containing
the firmware which is mentioned in MODULE_FIRMWARE() tags. The special
section is how we do it for the kernel too. That would take a little bit
of code in module.c to keep track of those sections and add them to a
list somewhere that firmware_class.c can see them, and then you have to
think about lifetime and locking issues.

But those were just preliminary thoughts -- I wasn't really planning to
implement it so I didn't go through it in detail.

An alternative approach might be to turn firmware blobs into actual
modules, which just register themselves with the firmware loader in
module_init(). I'm not sure I like that approach though, and depmod
wouldn't 'notice' them automatically so it wouldn't work with current
userspace. I've tried to be very careful to ensure that anything we do
here is entirely compatible with existing userspace.

-- 
dwmw2

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