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 00:39:13 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	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, 2008-09-11 at 10:23 +1000, Herbert Xu wrote:
> So I don't want to be in a situation where I install a new kernel,
> find that its wireless driver doesn't function correctly for
> whatever reason (which has happened to me previously at an airport),
> and then not be able to boot back into my old kernel to fix it
> because the firmware has now been overwritten.

Absolutely -- nobody should ever find themselves in that situation.
If a firmware changes in an incompatible way, its filename needs to
change too. The old one should still be available.

> I appreciate the thought on saving disk space.  However, I think
> the safest default is to install firmware (at least those from the
> kernel) into a version-specific directory. 

Even safer would be to have content-addressed firmware. Instead of
requesting it by filename, you request it by its md5sum. That way,
you're _guaranteed_ to have precisely what you expected.

But I think that's a bad idea too. As a general rule firmware isn't, and
shouldn't be, tied intimately to one particular version of the kernel.
It isn't even tied intimately to one particular version of the _driver_.

> Alternatively we should ensure that all firmware have version strings
> embedded in their names (e.g., ipw2200 versions their firmware so they
> would be OK), and that they're kept up-to-date whenever the firmware
> changes.

That's what we are doing already, as you say -- and what we should
always be doing.

And remember, ipw2200 isn't a particularly good example, because it's a
relatively recent driver and thus has always had its firmware shipped
_separately_ from the kernel.

All we're talking about here is the behaviour for the handful of older
drivers which I've recently dragged into this century by converting them
to use request_firmware(). Those drivers, by virtue of their age, are
mostly quite unlikely to receive _any_ kind of firmware update --
especially an update which changes their ABI.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

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