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]

Date:	Sat, 31 May 2008 23:18:57 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/18] firmware: moving drivers to request_firmware()

On Thu, 2008-06-05 at 18:11 -0400, Jeff Garzik wrote:
> Here is my "ideal firmware world":
> 
> * do NOT remove ability to compile firmware into the kernel

I have no intention of removing that.

>  (or into a module)

That I don't care about. If you can load modules, you can handle
request_firmware().

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

That would be a useful thing; currently the built-in firmwares cannot be
overridden but it wouldn't be hard to implement. Suggest it in 'diff -u'
form and it might just happen.

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

I don't think we have consensus on that, but as I said: post patches and
let's see if they get merged.

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

And binary isn't the preferred form either. We can cope with binary, but
it's not appropriate in the kernel source tree, imho.

When I make the shadow tree which contains the results of 'make
firmware_install', that'll have the binaries.

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

All these are true, but you're still missing the point that as I have it
it's already a _lot_ easier to process than when it was arrays of __be32
in some header file. I don't want to change to binary blobs as part of
what I'm doing this week. That's a _separate_ issue, and I'm not even
sure it's a goal I agree with.

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

I disagree. But feel free to post patches which get applied and prove me
wrong. I'm not going to object if you want to go convert a few more
drivers.

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