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 22:30:23 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jeff Garzik <jeff@...zik.org>, david@...g.hm,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.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.

Hi David,

> > I really think we should use /lib/firmware/`uname -r`/. I do see the
> > point here that I don't wanna overwrite existing firmware from other
> > installed kernels. Especially if modules_install will install the
> > firmware files.
> > 
> > So in case of non-Ubuntu distros we have to push a fix to udev, but that
> > is not a big deal. It should be a one-line change if I am not mistaken.
> 
> My concern with that is that even though it's a one-line change, it's a
> one-line change which people don't already _have_. We really do need to
> remain compatible with existing setups.
> 
> For _now_, I think it's much better to leave it in /lib/firmware where
> existing upstream udev will find it. Let's change udev ASAP and then we
> can talk about when it makes sense to change the default setting of
> $(INSTALL_FW_PATH) to match.

fair enough. What about keeping symlink in /lib/firmware, but actually
doing the install in a versioned directory?

> I'm not too worried about overwriting existing firmware
> in /lib/firmware. We very rarely change firmware anyway, when we _do_
> change it it's almost always compatible rather than having ABI changes.
> On the rare occasions that remain, the incompatibly changed firmware
> really ought to have a new filename so that older drivers don't pick it
> up when they want the old one.

Actually in some case we do. I think about the case where I have an two
years old kernel that came with the distro and would need that firmware
to make the driver work. However now we have the new firmware and it
falls over.

Breaking a distro install is worse then breaking a new kernel. At least
this is how I see it. I do like to have the distro setup as fallback or
rescue when I mess up.

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/