Re: Re: more evil firmwares found
Donovan Baarda wrote:
> G'day all,
>
> I'm not subscribed to the debian-devel list... feel free to repost to
> the list if this bounces.
>
> I've been browsing the kernel firmware threads in the archives, and felt
> the need to throw in my 2c.
>
> I have at various times worked on firmware for custom hardware. This
> often involved large sequences of hand coded hex.
Was the *entire* firmware ever hand coded hex? (How often? How long?)
If so, I guess some of these all-hex blobs could be believed to be hand
coded. Which would be GPL-compliant, then. Of course, if there was no
spec for how to write the blob in 'main', the blob would have to go in
'contrib'.
> It also often included
> binary blobs for which the concept of "source code" was not really
> applicable.
OK...
> With things like gate arrays, the preferred form for modification often
> is a large binary file. This file is "edited" using a large commercial
> application, often provided by the gate-array manufacturer. Anyone who
> has this application can "open" and modify this file. There is no source
> or compiler as such; the binary file is directly modified and directly
> loaded into the gate array. The format of this binary file is usually
> documented in the gate array spec's, and in theory you could use any
> tool to edit this file.
I see. OK, if it's fully documented, great, that's GPL-compliant! For the
DFSG, if you have no tool, that's 'contrib'; if you have the tool it can go
in 'main'.
If it's an embedded hex blob, however -- since the preferred form for
modification is a binary file -- then you need to supply the binary file,
not just the hex blob!
> However, some of the more complex chips and/or tools do use hardware
> programing languages and/or higher-level project files that are the
> preferred form for modification. These files are often highly dependent
> on the application that generates them, making them useless without that
> (commercial) application.
That means "contrib".
> Without details on the hardware, it would be nearly impossible to
> determine if the binary file you have is or isn't the preferred form for
> modification. You would have to take the distributors word on that.
A little documentation would help. Or indeed, the copyright holder's word,
rather than hypotheses and implications.
Still when I see something in the format "static u32 text[] = {...}; static
u32 rodata[] = {...}; ...", (as in the tg3 firmware) it looks pretty much
like a assembled executable file, and I have trouble believing that it
isn't.
> Even
> if you do have the "preferred form for modification", these files cannot
> be usefully modified without full specs on the hardware, and the
> application used to modify them.
Right. This is the 'contrib' problem.
> In one project I worked on, large firmware binary files were generated
> from a learning algorithm that was fed extremely large training data
> sets. The training data sets were themselves binary files generated from
> a variety of sources. The learning algorithm ran nearly a week to
> generate the firmware binary. After this binary was generated we
> developed our own tool that could inspect and tweak the binary file
> directly. The whole concepts of "source code" and "preferred form for
> modification" are kind of not applicable.
If you want the "preferred form for modification", well, you obviously
prefer the binary file, so it's that.
> How would this firmware blob
> be handled if it was up for inclusion in the kernel?
For the GPL, it would be OK. For Debian, if you supply the tool, it goes in
'main'. Otherwise, it's 'contrib'.
> Firmware walks the grey line between hardware and software.
Yes. If it isn't burnt into ROM, however, it's software. :-)
> The spirit
> of the GPL is that the "software" must be made available in a form
> useful for modification. With firmware, terms like "preferred form for
> modification" are largely useless as no form is useful for modification
> without the hardware specifications. This is why we need "Open
> Hardware".
So true; it isn't usefully free without hardware specs. Like so much.
>> > Hasn't anyone considered that maybe the binary blob *is* the source
>> > code?
>>
>> Yes, and we've pretty much rejected it. While they might actually use
>> ASM, I've yet to run into someone who regularly codes (and modifies
>> their code) in machine language.
>
> In firmware for custom hardware I've found it very common to have long
> runs of hex data hand coded in C arrays. These arrays are the preferred
> form for modification, and no scripts are used to generate them.
Hooray! A fact!
Are they ever the *entire* firmware?
> A typical example would be hardware with large numbers of configuration
> registers (up to 256 registers would be fairly common, but I would not
> be surprised if there was hardware out there with many K's worth of
> registers). Each register needs to be loaded with specific values that
> are evaluated by hand from the hardware's spec's. Evaluating many
> hundreds of hex values and typing them into an array is painful, but it
> only needs to be done once, so you do it by hand. During testing you
> might find you need to tweak the values, which is again done by hand.
So here you would
*specifying the width of the registers
*make an array of items of that width
*loading it in some clear way, *not* written in hex, into the registers
Anyway, would you call such an array 'microcode'?
I have to assume that the 'microcode' in the r128 and radeon drivers is, in
fact, microcode.
If it really looks like a register initialization array, I'll believe that
it is, and that it's GPL- and DFSG-OK. It it doesn't, but I'm *told* that
it is, I'll believe that it is. Otherwise, I can't see why anyone would
believe that it is.
> There are several reasons why a company providing "Open Source" like
> this would not or could not explain where the numbers come from.
> Sometimes, explaining the numbers would reveal more about the hardware
> than they are prepared to reveal.
that == not free.
> Often they don't know; all they have
> is the same source you do, and the incomprehensible scribbled
> calculations of the engineer who wrote it were either filed in the
> trash, or are buried in a working file somewhere with configuration
> management.
Well, that's OK, of course.
--
There are none so blind as those who will not see.
Reply to: