[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: more evil firmwares found

On Sun, Apr 25, 2004 at 03:39:55PM -0400, Nathanael Nerode wrote:
> Yep.  I have not complained about those which are not obviously microcode. 

You're right, you have not.  My post also wasn't targeted at you.
Without a clear policy on the matter, I believe we are in danger of
crossing the bounds of reason.  I intended to demonstrate that the
current method of determining whether an otherwise free binary blob is
not DFSG-free, is too much of a "put a finger to the wind" approach for
it to scale to the size of this project.

> Putting burden of proof in the wrong place, again.  At the very least, if it
> looks and smells like machine code, and I have no evidence that it isn't,
> I'm going to assume it is.  Anything else would be stupid.

Stupid?  It looks like two different approaches to the same problem.
Your approach presumes guilt and waits for someone else to confirm
innocence.  It may be the safest approach in a ridiculously pedantic
way, but I don't see how it renders all other approaches stupid.
Another approach would be to tread carefully around unidentified blobs,
separating them from program material when possible, but not sending
them to non-free on the sole basis that we have not the means to
identify them.

> How about the label "microcode (from ATI)"?

In this given instance, certainly.  Do the circumstances of this
instance map onto all instances of the same general problem?

> Anyway, perhaps you're thinking too abstractly.


> For any given blob, the question is "is this the preferred form for
> modification?"  If it looks like it's a large quantity of microcode, then
> given that almost nobody hacks large quantities of microcode in hex, we
> figure it's probably *not*.  If it looks like it's something else, we deal
> with that in the way that's appropriate for that.

What is a large quantity?  The current forms of microcode seem to be
less than 1K large on average.  I can say with absolute certainty that I
have maintained assembly listings of that approximate size without the
help of a high-level compiler.

In any case, the DFSG says nothing about the preferred form of
modification whatsoever.  It says "source".  An assembly listing of a
program originally compiled in C would satisfy the DFSG requirement.
Additionally, if something is not a program, its source is not required
by the DFSG.  This is only an issue in the GPL-compatibility context:

> > said tool in our hands to verify such claims.  Also, if we went this
> > route, a binary-blob which was previously free could be rendered
> > non-free by a vendor suddenly creating a tool which generates such
> > blobs.  Would that make any sense at all?
> No, that's not right at all.  It's a *particular* blob we're talking about,
> and it's the factual question of whether it is the preferred form for
> modification.

If no high level tool exists, then the binary is the preferred form.  If
a high level tool exists, and people use it to generate the binary, then
the high level source is the preferred form.

> In the cases which have been removed, I haven't met anyone who's admitted to
> modifying the 'blob' form of microcode, and it's a form which is almost
> always modified in a different form.  (If people said "Oh yeah, we modify
> the hex," that would be factual evidence that it *was* the preferred form.)

Finding out how people do not modify the binary is irrelevant.  The
question is, have you met anyone who confirmed that they modify it in a
higher-level form which is then compiled to the binary form, and do the
numbers of those people outweigh the numbers who hand-hack it?  If so,
then the binary is not the preferred form.

This is why the "preferred form" clause in the GPL needs work.
Preference is subject to individual taste and the constraints of a given
project.  The most convenient metric for preference would be the results
of a survey.  Anything else is just handwaving.

> In contrast, in the case of the various lookup and transformation tables in
> the sound drivers, which are *also* hex blobs, their creation is
> documented, and I can believe (in some cases) that they are modified by
> hand.

Excellent!  That is the type of information that needs to accompany
these blobs to remove all question as to their GPL compatibility.

Back to Debian:

> The firmware hunks we're talking about are definitely executable programs,
> though.  Nobody has actually claimed that they aren't.  Although some
> people have claimed that "we don't know", we're actually pretty sure.  So
> Debian requires source for them to go into 'main'.

Here's where my personal involvement comes in.  The WARP microcode in
the MGA XFree86 driver is to be removed to non-free.  I have seen
nothing that indicates the microcode is a program, besides the fact that
it is referred to as "microcode".  I have never seen any technical
details on the microcode or the WARP core aside from the slim mention in
the databook, and the smashed-together doc on how to send vertex data
and 3D commands to the "microcode" that was released in a previous life
of Matrox.

So we have a couple hundred bytes of "microcode" for each "program" that
is loaded into the "processor".  Without more documentation or
confirmation from Matrox on the nature of the blob or the G-series
chips, there is nothing, besides the name "microcode" in the variables,
to lead us to believe that these things are actually programs and
user-modifiable to produce different behavior.  After all, I could just
start naming random binary blobs asdf_microcode in my programs, just to
induce false positives with this heuristic.  For all we know, they
are configuration images ala configurable logic devices, or a sequence
of bytes that are sent to initialize various registers within the WARP
or to configure the order of existing logic units within the hardware.
It is not a program if the state machine does not use the data to
determine what state to proceed to next.  If it is not a program, DFSG#2
does not require source.

So anyway, this is getting moved to non-free, and the situation will be
much worse than before.  There are two possibilities that are acceptable
to me:

1) mga_ucode left alone in XFree86 driver (not going to happen, as this
blob-without-source is part of a program and would cause XFree86 driver
to fail DFSG#2)
2) mga_ucode split out to a separate file loaded at runtime by XFree86
driver and distributed with XFree86 since it is assumed to not be a
program and thus satisfied DFSG (my preferred approach)

There is a third approach that still sucks, but isn't quite so bad.

3) mga_ucode assumed to be guilty program-without-source. moved to
non-free.  XFree86 driver checks for its existence and loads it if it is
there.  If not, 3D functions don't work, nor does RENDER.  I think 2D is
still operational.

But instead, we are doing the following:

4) mga_ucode moved to non-free.  Kernel ioctl developed to load a
microcode. XFree86 driver has to call this ioctl every time it wants a
new ucode loaded, and a userspace agent is invoked on its behalf to find
the microcode file and load it.  Now we have 3-4 context switches per
polygon depending on how many pipeline stages are needed, since there is
a different ucode for each pipeline stage (and also different ucodes
when multitexturing is being used).

I am going to hate my mga card really quickly if this approach is
seriously taken.  But I seem to have little leverage to convince people
that assuming ucode==program and waiting to be proven wrong is a worse
idea than the inverse.  Seriously inconveniencing users in the face of
dubious and perhaps not even any gain in freedom does not seem to be a
good plan to me.  But I am only one voice.

I can undermine my own argument here by saying that I feel
inconvenienced by Matrox in that I feel that it is possible to implement
T&L pipeline stage on G-series hardware, but cannot because of lack of
docs or source to the current microcode (if it is a program).  But by
saying that, I am making an assumption that the hardware is capable of
even doing such a thing, and that the current "microcode images" are not
just playing a connect-the-dots game with fixed hardware functionality

We can assume one way or the other in this case.  If we assume they are
programs and fail DFSG#2, the user gets a serious inconvenience, and if
it is a false positive, we have not gained anything in freedom; and if
the guess happens to hit the mark, we still have gained no leverage with
Matrox, though we have succeeded in our goal of freedom.  If we assume
they are not programs, it is possible that a false negative will be
applied.  Either way, in the short run, the user will not be
inconvenienced.  In the long run Matrox will not change their ways.

It is a trade-off of a definite outcome versus a roll of the dice.  We
are trading a 100% chance of an inconvenience to users, for a
less-than-100% chance that the blob in any particular case is a
program-without-source and is thus hampering the freedom of the user.

> > If programs(=software, then the given statement is true, if we consider
>  Do you mean != perhaps? or <= ?

Subset relationship.

> > non-executable supporting materials not to be software.
>  Do you mean "to be software, but not to be programs"?

Yes.  I keep making that slip and it keeps undermining my argument. :)

Ryan Underwood, <nemesis@icequake.net>

Attachment: signature.asc
Description: Digital signature

Reply to: