linux-kernel - Re: [PATCH 00/18] firmware: moving drivers to request

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: <4848648D.8010501@garzik.org>
Date:	Thu, 05 Jun 2008 18:11:25 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	David Woodhouse <dwmw2@...radead.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/18] firmware: moving drivers to request_firmware()

Here is my "ideal firmware world":

* do NOT remove ability to compile firmware into the kernel (or into a 
module)

* firmware should be field-replaceable, even if one was compiled in

* the preferred form of firmware is one or more binary blobs, stored in 
a regular [filesystem|git] binary file.

* the preferred form is NOT ascii C source, or any other format other 
than the native format that the hardware wants.  Remember, the vendor 
only provided an ASCII-ized firmware because our system required it that 
way, not because that's the preferred form.

* in-tree firmwares should be stored in one or more binary files in the 
tree, not in C source code or .ihex files.

* when firmware is stored as binary blob, it is easier for
	(1) vendor to replace,
	(2) developer/user to compare/verify using sha1,
	(3) does not require a C compiler or binutils to unpack

Thus, if you are going to be touching the in-tree firmwares at all, it 
doesn't make sense to convert from C source to any format other than 
native binary.

	Jeff

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