linux-kernel - Re: [PATCH] firmware: Allow release-specific firmware dir

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: <20080911220700.GD5823@kroah.com>
Date:	Thu, 11 Sep 2008 15:07:00 -0700
From:	Greg KH <greg@...ah.com>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Marcel Holtmann <marcel@...tmann.org>,
	Thierry Vignaud <tvignaud@...driva.com>,
	David Miller <davem@...emloft.net>, jeffm@...e.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org
Subject: Re: [PATCH] firmware: Allow release-specific firmware dir

On Thu, Sep 11, 2008 at 02:15:25PM -0700, David Woodhouse wrote:
> On Thu, 2008-09-11 at 13:57 -0700, Greg KH wrote:
> > On Thu, Sep 11, 2008 at 01:38:38PM -0700, David Woodhouse wrote:
> > > On Thu, 2008-09-11 at 13:15 -0700, Greg KH wrote:
> > > > This is the firmware that is in the kernel source tree, that has been
> > > > moved to use request_firmware, and was originally tied tightly to the
> > > > kernel drivers themselves.
> > > 
> > > Not really. Most of it hasn't changed for years; it isn't _really_ tied
> > > that closely to the kernel. 
> > 
> > Some are and some aren't (I have two in my -staging tree that are
> > changing as the driver changes, so it does happen.)
> 
> That's fine. Just make sure the filename changes when an incompatible
> change is made to the firmware -- just like you handle sonames in
> libraries. It's not hard, and you should _always_ have been doing it.
> 
> And it's a completely bogus example _anyway_, because you're not adding
> this extra firmware to the kernel tree.

No, it shows that the firmware does change over time.

> All I've done _recently_ is a bit of a sweep on the stragglers. And
> because of the amount of stupid whining, I made it possible to keep it
> in the kernel tree rather than just evicting it, as we did in the past.

But it was that "sweep" that has caused problems by having the kernel
put these files into the lib/firmware directory, without any version
information unlike any other file that our kernel installs.

That's the only point here.

It seems that the point that it is a bad thing for multiple kernel
packages to be installing into the same location, no matter if the file
has the same content or not (date will change which will cause
problems) isn't coming across here.  Why is that?

Think of the very real example here:

	rpm -Uhv kernel-2.6.27.1.rpm
	rpm -Uhv kernel-2.6.27.2.rpm
	rpm -e kernel-2.6.28.1

Now what just happened to the firmware that the 2.6.27.2 kernel package
had installed into lib/firmware?  It would be gone.  That is if rpm even
_allowed_ the second kernel package to be installed due to the
conflicting files.

So distros _HAVE_ to install the kernel-based firmware into
lib/firmware/uname-r/ to get their packaging to work, and to prevent bad
things from happening if a user installs their own kernel by hand and
then removes the kernel package.

That is why this patch was submitted, it is necessary.  If every distro
has to carry it on their own, due to packaging requirements, don't you
think that it should be in the main kernel tree as well?

> > > You can just ignore what the kernel ships with, and install the firmware
> > > from the linux-firmware.git repository instead.
> > 
> > So you are now forcing distros to ship the linux-firmware.git repo
> > instead?  That's not nice and is a totally new dependancy for them to
> > handle.
> 
> Not at all; that's the ideal situation, but nobody's forced to do it
> that way.

It's either use that package or add a patch that upstream seems to be
objecting to.  That seems a bit "forced".

> > What about the very basic fact that kernel versions will stomp on files
> > from other kernel versions if you install multiple kernels on the same
> > machine?  That's just bad and ripe for problems in any package
> > management system.
> 
> Only if you do stupid things in your packaging. So don't do that.

How do you expect anyone to package this up so that no conflicts occur?

thanks,

greg k-h
--
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/