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: <48C8D33F.2050804@suse.com>
Date:	Thu, 11 Sep 2008 04:13:51 -0400
From:	Jeff Mahoney <jeffm@...e.com>
To:	Marcel Holtmann <holtmann@...ux.intel.com>
Cc:	David Miller <davem@...emloft.net>, dwmw2@...radead.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org
Subject: Re: [PATCH] firmware: Allow release-specific firmware dir

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcel Holtmann wrote:
> 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.

They "should," but is that happening now? Out of all the firmware blobs
installed with 2.6.27-rcX, only the edgeport drier actually versions
them - and they're versioned because the driver requires different
versions for different hardware.

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

Well, what we're doing is including the firmware blobs inside the kernel
packages. So, yeah, we install all the firmware blobs again, but they're
installed with the modules that we're installing all over again anyway.
All the firmware blobs currently included in 2.6.27-rcs total about
540k, so the wasted disk space is largely negligible when compared to
the size of installing an additional kernel and module set.

We check /lib/firmware/$(uname -r) /lib/firmware
/usr/local/lib/firmware, in that order.

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

In what case? After you install a new kernel and then reboot? You have
the same problem with the modules that need the firmware blobs.

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

It works just fine until the user wants to install an additional, newer,
kernel and the blob has changed but the filename hasn't.

- -Jeff


- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkjI0z8ACgkQLPWxlyuTD7LPkQCeOGxTOsUivMmjabTrkHd7ssJ3
OBIAnidEMgduuQ4WCXN8JSEhJ4Gij7Iv
=3Lng
-----END PGP SIGNATURE-----
--
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/