linux-kernel - Re: RFC: Moving firmware blobs out of the kernel.

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: <1212095891.18530.12.camel@shinybook.infradead.org>
Date:	Fri, 30 May 2008 00:18:11 +0300
From:	David Woodhouse <dwmw2@...radead.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Theodore Tso <tytso@....edu>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	James.Bottomley@...senPartnership.com,
	ksummit-2008-discuss@...ts.linux-foundation.org,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org
Subject: Re: RFC: Moving firmware blobs out of the kernel.

On Thu, 2008-05-29 at 15:12 -0400, Jeff Garzik wrote:
> I like your idea, all the way to the point where you actually remove the 
> firmware file from the kernel tree :)

I've been careful to ensure that what I'm doing is a benefit even
without that final step. But I still think that final step is useful
too.

> If the firmware has a compatible license and is required for critical 
> operations like booting the machine, built-in firmware should remain an 
> option. 

Well, 'compatible licence' is a loaded question. It takes a fairly
wilful misinterpretation of 'mere aggregation', IMHO, to see what we're
currently doing as legal -- but I was trying to avoid that discussion
since it tends to devolve into name-calling and nobody's _actually_
right until/unless it's decided by a court.

But sticking to the technical side -- with what I have now, it's
_easier_ to build external firmware into the kernel than it was before.
My original testing was done with a kernel with the libertas
'usb8388.bin' firmware built in to it, for example. That was never
possible before.

Having firmware files in a separate tarball doesn't prevent you from
building them into your vmlinux if you want to. And there are some
companies who wouldn't allow their firmware to be distributed in the
kernel source tree because it's under GPL, but _would_ consider putting
it in a separate 'kernel-firmware' repository instead. So this should
_also_ mean we can ship more firmware, more easily.

Hell, with git submodules you almost don't need to notice the
difference, do you? Just check out kernel-firmware as a subdirectory of
the source tree (or point CONFIG_BUILTIN_FIRMWARE_DIR at wherever you
_did_ check it out), and you're done.

>  For certain embedded cases, I could certainly see that 
> in-kernel firmware being the best method for firmware distribution, for 
> both $Platform's users and $Platform's developers.

It is not my intention to remove that possibility. I believe I have made
it _more_ feasible; not less.

-- 
dwmw2

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