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]

Date:	Thu, 11 Sep 2008 09:44:28 +0200
From:	Marcel Holtmann <holtmann@...ux.intel.com>
To:	David Miller <davem@...emloft.net>
Cc:	dwmw2@...radead.org, 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

Hi Dave,

> > It's definitely not something we should be doing upstream though.
> 
> So you think it's ok that every Debian user has to learn this
> magic incantation just to use current kernels?
> 
> I don't think it's nice to break things like this on people,
> especially such a large group.  Getting this stuff to work is hard
> enough, and we're just putting yet another barrier into the situation
> and that can only mean less testers and contributors.
> 
> I do know several people who aren't testing and contributing because
> the whole firmware shakeup is so bolixed and they really are exasperated
> after spending hours trying to get it to work.

it is that the Debian maintainer screwed this up. Upstream never
promoted kernel versioned directories for the firmware. I had a long
discussion with Dave about it at OLS and using the kernel version is
just plain wrong. The driver maintainers should version the firmware if
they break it in an API incompatible way.

To shed some light into the problem with Debian/Ubuntu. They install the
firmware in /lib/firmware/`uname -r`/ and everytime they bump their ABI
number, they have to install all the firmware again. This is just
braindead. Their udev script actually checks /lib/firmware first and
then the kernel versioned directory. So that is just fine.

Problem comes when installing let say 2.6.27 since then the firmware
will be looked up in /lib/firmware/ and /lib/firmware/2.6.27/ and
actually it will not be found. Since it is in /lib/firmware/2.6.26-xx/
or something similar.

So having the kernel install everything in /lib/firmware works just fine
with every distro. However looking for firmware that is not shipped with
the kernel, we have a problem since Debian/Ubuntu just not installs it
in the right directory. And there is nothing the kernel can do about it
since it will not touch firmware it doesn't ship. The distro has to fix
their firmware or the users have to place a copy in /lib/firmware/ where
it actually should have been in the first place.

Regards

Marcel

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