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 17:57:09 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	jeff@...zik.org, 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 Mon, 14 Jul 2008, Jeff Garzik wrote:
>> IMO the newly added /inability/ to build firmware into kernel modules
>> is a clear regression.
> 
> IMO you're being stupid.
> 
> How about explainign why it makes any difference what-so-ever?
> 
> If you can load the module, you can load the firmware. Claiming anything
> else is just _stupid_.

Sure, in theory it's that simple. Here's a concrete example that shows how 
things are harder in practice.

I use the 'make deb-pkg' target (from scripts/package) to build my Debian 
kernel packages from git. So that needs to be adapted to include
/lib/firmware. No real problem so far.

So then I build 2.6.27-rc1 and install it. Great.

You release 2.6.27-rc2 and I build it. Ouch! It fails to install, at least 
if I want to install it _alongside_ 2.6.27-rc1 or other kernels (which I 
do!). Why does it fail? Because dpkg's package management does not allow 
one package to overwrite files already "owned" by another package.

So, how is this solved by Debian for already existing firmware packages? 
Basically by making a separate package for each firmware file (or 
driver). This works because there are not too many of them, but having a 
huge number of tiny packages is a nightmare by itself.

But anyway, the dep-pkg target will have to be made smarter than it is now 
if it's to deal with this [1]. And at least currently it is broken.

If I were able to compile firmware into the modules, the problem would be 
solved in one go.

I don't know how the Debian kernel team plans to deal with this for distro 
kernel packages. They probably _do_ want to keep them separate [2]. Maybe 
by grouping firmware for really common drivers into 
firmware-basic-drivers or something along those lines.

Cheers,
FJP

[1] Only quick solution I see is to have it install the firmware in a 
versioned directory and have the postinst copy things from there to
/lib/firmware.
[2] As one of the developers for Debian Installer I'm not looking forward 
to the complications that is going to cause for us and users.
--
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/