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 04:23:14 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	David Miller <davem@...emloft.net>
CC:	david@...g.hm, torvalds@...ux-foundation.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.

On 15-07-08 03:52, David Miller wrote:

> From: david@...g.hm Date: Mon, 14 Jul 2008 17:51:37 -0700 (PDT)
> 
>> I agree with this, but the proponents of the seperate firmware are
>> listing the fact that the firmware doesn't tie up ram as one of the
>> big reasons for making the change.
> 
> Exactly.
> 
> Otherwise these firmware changes are utterly pointless.

The point of them is legal. Which everyone knows so could perhaps that 
particular dance be done away with?

The current patches allow to

1) load the firmware from userspace
2) load the firmware from the kernel image (vmlinux)

They lack the ability to load the firmware from the module image.

 From a technical standpoint that seems an odd setup. As a driver author 
you'd either be satisfied with loading the firmware from userspace, or 
if for example you feel you're very much tied to your specific firmware, 
you want it to be as close to you as possible -- in the kernel image 
while you yourself are a module makes little sense. You couldn't for 
example just copy the single module around.

That seems a clear technical point to fix but after that, the point is 
legal. At least for existing drivers, this consists of distributions 
worrying about GPL consequences and wanting to seperate out the existing 
firmware blobs.

They do worry -- whatever those worries might be worth -- so there's the 
point. You may feel it not a good point but that's something other than 
no point existing.

I followed along on these flamewars and I'd say to reject these current 
patches on technical grounds until the ability to build the firmware 
into the module exists and merge it after -- even though people might 
feel there's little or no upside to them, I'd say there's little of no 
downside either once that ability is in.

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