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: