[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:
<snip>
>> 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.... ;-)

<snip>
> 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: