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:	Thu, 05 Jun 2008 17:33:23 -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()

David Woodhouse wrote:
> On Thu, 2008-06-05 at 17:01 -0400, Jeff Garzik wrote:
>> If the sha1 sum of what is in the kernel tree differs from what the 
>> vendor provided, then it is OBVIOUSLY more difficult to verify that
>> you have the original firmware as provided by the vendor.
>>
>> Put the binary blobs into the git tree, __without modification or 
>> wrapping__.
> 
> We don't have them in that form right now. Of the firmware blobs I've
> encountered so far -- even the ones which were in a file on their own --
> none of them are in binary form; they're _all_ in some ASCII
> representation which can be processed with 'diff'. That includes char
> arrays, arrays of larger integers which need endian-awareness, 'hex
> record' structures, and probably a bunch of other abominations I have
> yet to encounter as I work through them.
> 
> None of them have just been binary files in the source tree.

Right.  And now you are creating Yet Another Format, rather than 
rendering the firmware back into the preferred format:  binary blob.

_If_ you are changing form of current in-tree firmwares at all, there is 
no excuse not use direct binary blob -- the least common denominator for 
all relevant operations.

Storing the firmware in .ihex is just as bad as storing the firmware in 
source code -- it's a pointless wrapper that makes firmware verification 
and updates far more difficult than they should be.

	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/