linux-kernel - Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN

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: <200805252039.17673.mb@bu3sch.de>
Date:	Sun, 25 May 2008 20:39:17 +0200
From:	Michael Buesch <mb@...sch.de>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	Johannes Berg <johannes@...solutions.net>,
	David Woodhouse <dwmw2@...radead.org>,
	Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org,
	aoliva@...hat.com, alan@...rguk.ukuu.org.uk,
	Abhay Salunke <Abhay_Salunke@...l.com>, kay.sievers@...y.org,
	Takashi Iwai <tiwai@...e.de>
Subject: Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option

On Sunday 25 May 2008 20:23:46 Marcel Holtmann wrote:
> > The fact that userspace uses the key as a filename is maybe  
> > unfortunate,
> > maybe fortunate, but shouldn't have anything to do with what sort of
> > keys the kernel allows.
> 
> I disagree with you. The kernel should be free of these kind of  
> subdirectory stuff. We saw devfs failing and we have a flat device  
> node names in the kernel. Why do we have to duplicate information in  
> the firmware filenames where we have all the information already  
> present in the driver model. The reason that people are lazy doesn't  
> work for me.

I think you don't really understand what we are trying to explain.
So I'll try it once again.

We are _not_ saying that having hierarchy policy decisions in the kernel
is a good thing. It's just the case that we _currently_ have this kind
of firmware filename, that happens to _map_ to a hierarchy policy
currently made by udev.

That's either unfortunate (to you) or fortunate (to me).
In either case we have to live with it and we can _not_ break it.
By introducing a policy that forbids the use of the slash, we do break
this.

> > Also, you said above (quoting again):
> >
> >> You are fully
> >> exploiting the request_firmware() interface and making any kind of
> >> userspace policy impossible.
> >
> > That's not true at all. If you decide that the userspace policy should
> > be to load $modulename/$firmwarekey then you'd maybe have something
> > like /lib/firmware/b43/b43-test/ucode5.fw
> > and /lib/firmware/b43/b43-osfw/ucode5.fw
> > and /lib/firmware/b43/b43/ucode5.fw, this doesn't preclude the use.
> >
> > Now, if it had been like that from the beginning, Michael probably
> > wouldn't have used the string "b43" (or "b43-*") but rather requested
> > "broadcom/ucode5.fw" by default and "osfw/ucode5.fw" for the open  
> > source
> > firmware, but since it's just a key that doesn't matter.
> 
> That something works at the moment is not a reason for me not to fix  
> it and improve the current framework around firmware loading. I have  
> been a lot of times saying that the request_firmware() should not  
> include "/" in the filename and driver authors followed it. Some of  
> them did it anyway and so these need fixing now.

But to forbid usage of "/" is the _wrong_ way to go, as it breaks
existing setups.

b43 users are not going to accept re-installing or moving the firmware
files to another place. We had that in the past. It will result in a _lot_
of angry complaints like "How dare can you break my setup!".

-- 
Greetings Michael.
--
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/