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

Re: more evil firmwares found

Ryan Underwood wrote:

> On Sun, Apr 25, 2004 at 03:39:55PM -0400, Nathanael Nerode wrote:
>> 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.
Assembly, you say.  :-)  This is not assembly; it's machine code.  Frankly,
if we had assembly, we'd be happy.

> 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.
I have met precisely 0 people who have edited it, but everyone I've talked
to would prefer another form if they had to.... ;-)

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

We would like to make 2D functions work without the microcode, of course.  I
believe this will happen if the DRM module is not loaded.  (Right?  I
haven't looked into that much yet.)

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

Actually, it's going to be done differently; all the microcode is loaded
into graphics card memory at once during initialization of the DRM module,
if I'm not very much mistaken (yes, I've been working on it); switching it
to be loaded from userland should cause one context switch during
initialization, period.  (Possibly several if I implement it a bit
differently, but all during initialization.)  XFree86 does not actually
need to do anything; the DRM module simply uses the kernel's facility for
requesting microcode from userland, and if it doesn't find the microcode,
the DRM module doesn't load.  That's the idea, anyway.

There are none so blind as those who will not see.

Reply to: