On Sun, 19 Jan 2003, Peter Finderup Lund wrote:
>> engineer knowing these things can save themselves a _LOT_ of time
>> in tracking down red herring types of bug reports.
>
>Precisely.
>
>> show "nvidia" as the driver. This is already very aparent, so no
>> special "tainting" infrastructure really needs to be in place.
>
>Yes, but it is not very clear -- I'd like it to be displayed at the bottom
>of the error message instead of buried somewhere inside a log file. We
>want people to see it and understand it /before/ they send "bug reports".
I don't see the difference. If you are going to debug a driver
a user is using, then one of the first things you look for in the
log file is what driver they're using. At that point it is
obvious wether it is proprietary or not in the majority of cases.
I see no value to repeating this information all over the place,
and I would suspect most other X developers wouldn't find value
to it either, however I'd be interested also in hearing their
thoughts. I'll assume lack of a response is more or less
agreement.
>Also, people seem to copy and paste the error message and attach the log
>file. It is much faster to skip/give standard reply if the "tainted"
>message is in the error message instead of in the log.
How is it 'tainted' though? The "tainted" message in the kernel
more specifically refers to non-GPL code being used, and/or any
module being force-loaded. In the XFree86 case, the X server is
not GPL, so GPL-forces-you-to-do-what-the-developers-want doesn't
apply to proprietary kernel modules. So the "P" taint flag
doesn't apply due to licensing non-constraints.
The X server does refuse to load modules with incompatible ABI
however, which is similar in nature to what the kernel does with
proprietary modules not compiled for the kernel you're running.
The X server has a commandline override switch for this, however
I doubt seriously if anyone ever uses it or needs to. The
proprietary X modules out there tend to track and be compatible
with the X servers shipped for the last 2 years roughly if not
older. I think the proprietary modules out there are available
for 4.1.0 and later for the most part.
So, this means modules are available that use the same ABI as any
server you're likely to be using, and that force-loaded modules
are a rare occurance. I don't know if the X server logs the fact
that the ABI override is being done or not, but I would suspect
that it does. If so, this could be considered like the "F" taint
flag in the kernel. Note however that while the Linux kernel
refuses to load modules from different kernel versions by
default, and the kernel tends to be released quite often - at
least in new major kernel series, the X server in contrast tends
to be released once or twice per year tops, so proprietary
modules tend to always be ABI compatible with current X servers.
The exception might be a new X server such as the current
development code, which might be ABI compatible with a prior X
release possibly. I don't see this as a real problem however.
As maintainer of the XFree86 packages in a major Linux
distribution, I can say from experience, that it is very easy to
tell if a user is using a proprietary X module fairly quickly,
and having the X server tell me this when an error occurs
wouldn't help me personally out at all. First thing I want to
know is "what video card is it". After I know that, if it is one
of the vendor's whom have proprietary drivers, first thing I look
for immediately is "is it the proprietary driver?" by looking at
the driver module load line. If it is the proprietary driver, I
can then redirect them to their hardware vendor or public mailing
lists for support, and/or request they reproduce the problem with
the appropriate open source driver instead (if one exists for
that hardware).
>> XFree86 would have to change the license to GPL, or add some
>> clause to the license in order to implement some form of tainting
>> infrastructure.
>
>Would never fly -- and shouldn't!
Indeed. I've heard other people suggest the X source be released
under GPL license before. While I am an avid GPL supporter, and
GPL is the license I use on almost everything I do personally,
there are some weird legal questions that arise should the entire
X server be GPL licensed. In particular, proprietary modules
loading into the X server are doing runtime linking. For all
intents and purposes, X server modules are "plugins". Under the
GPL, a GPL licensed X server would make any
plugins/modules/drivers that link into it at runtime 'derivative
works'.
That would create the "is a proprietary X driver module violating
the GPL license?" question, of which no clear answer would exist.
Assuming the vendor could compile said proprietary module against
an MIT X server, and someone could load it into a GPL server, the
vendor wouldn't really be violating the GPL - if the ABIs are the
same of course. Then there is the case where a user loads a GPL
X module, and a proprietary module into any X server. Is the GPL
module and proprietary one conflicting?
I think these legal issues would have no real clear answers, and
I probably myself could argue either side of the debate that
might arise in such a situation.
However... I seriously doubt that the license of the X server,
or of XFree86, or X11R6.*, etc. would ever be changed away from
the MIT license anyway. Certainly people will release new code
under whatever license they wish, and certainly there exist now
both GPL and proprietary modules out there, as well as a variety
of other modules.
>> One thing that would be a much more useful parallel to the
>> kernel's taint feature, would be some form of digitally signed
>> modules. Have an option that is off by default in the X sources
>> that allows the builder to have the modules all digitally signed
>> at build time. This presents a number of options.
>
>Now, /that's/ a good idea. But does it have to be signed? Wouldn't a
>good hash (MD5?) be enough?
I thought of using MD5 at first, however the problem there is
that someone can simply compile new modules themselves and
include an MD5 in them also. If the MD5 were displayed in a log
file for example, I'd have to manually compare the MD5 with a
list of MD5's of various X servers we've shipped in the past.
To have the X server do this itself, it would have to keep an
internal list of MD5's of the modules built when the X server
itself was built. The X server would check the modules it is
loading with the MD5 sum stored. That would work ok for the case
where the user adds an external module to the X server that
didn't ship with X, but it would fail if the user patched the X
server completely and rebuild the whole thing. The new build
would always have correct MD5 sums.
The digital signing with a vendor key ensures that if the X
server is recompiled completely, the modules either wont be
signed, or will be signed by the user's key instead, and that
information can be displayed easily in the log file. If digital
signing with a randomly generated key that is thrown away at
build time, even the vendor can't build new modules and have the
X server indicate they are signed properly. This would allow me
for example to release Test Drivers That Suck(TM) on my ftpsite
that people could just drop in to test, and if I get bug reports
in the future from someone using one of these drivers, if they
haven't stated straight out that they're using them, the X server
would tell me that the module they're using isn't signed. I can
then say "where did you get the foobedoo_drv.o module you're
using", and they'll say "from your ftpsite, sorry I forgot to
mention that". It could help cut down on troubleshooting red
herrings a lot IMHO.
>I agree with you that it should not be used as a security mechanism and
>loading unsigned modules should never be blocked.
Not be blocked by default, but rather having the "option" to
block non-signed modules is something useful I think, although I
would personally have it default to off in any installation,
perhaps allowing the option in a config tool.
>It only has merit for improving the bug report process, both for the
>end-user ("oh, it didn't work and it suggests that I try with one of the
>modules it knows about instead. Ok, I'll try that and see if it works
>better. And if it doesn't, then I'll at least know not to blame the
>XFree86 people") and the XFree86 developers.
Indeed. I've got some of the bits and pieces to implement
something like this in a "hackish" sort of way, but I've not
fiddled with it much. I think what I'd probably do if I were to
pursue this, would be it implement the ugly hack as a proof of
concept, then investigate a more proper and clean implementation
that could be offered back to the XFree86.org tree.
It'd probably be only a couple of days worth of work I think, but
would require a bit of ELF loader love, which is why it's way low
on my fun-things-to-do list. ;o)
--
Mike A. Harris
_______________________________________________
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
