On Sun, 19 Jan 2003, Peter Finderup Lund wrote: >Perhaps XFree86 should learn a trick from the Linux kernel -- if you load >a binary module that isn't open source then the kernel becomes "tainted".
That's an interesting idea at first, but it doesn't really IMHO hold any real world value in the end, but let me explain. The kernel's tainted flags are present to try to help kernel engineers know that a kernel may have had proprietary or other non-GPL kernel modules loaded, or the user may have "forced" a kernel module to load that may possibly not be compatible with the kernel. The ultimate goal of it, is to be an aide to developers in weeding out bugs that are possibly due to factors they are not able to do anything about, such as a proprietary kernel module being buggy and scribbling all over kernel memory. The "P" flag indicates that the driver is non-GPL, while the "F" flag indicates that the driver was force-loaded into the kernel, and could possibly be the source of the crash/problem. An engineer knowing these things can save themselves a _LOT_ of time in tracking down red herring types of bug reports. >In case of a kernel panic it will say that it is tainted -- it >is a way to cut down bugreports/redirect them to the right >place. A kernel panic with tainted modules loaded is almost >never the kernel's fault -- and in any case the kernel >developers don't stand much of a chance for debugging it. Indeed, much of what I've said above. However, if a user is using Nvidia's proprietary driver, the X server log file will show "nvidia" as the driver. This is already very aparent, so no special "tainting" infrastructure really needs to be in place. ATI's fgl driver similarly reports itself in the log file, and is not hard to see. It's one of the first things a developer looks for, is what driver is being used, and what card. There could however be binary only drivers that are based on the XFree86 drivers. How would one know however? How could you really flag this? It would be rather difficult. For one, XFree86 is not GPL licensed, it is basically MIT licensed. If the modules were built with some special license tag, any vendor shipping a proprietary driver could use that same tag in their driver also, and not be violating the license, since the MIT license allows you to do pretty much anything with the code. 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. The drawbacks to changing the license however would extremely far exceed any advantages that it provided to developers. The 2 most widely used proprietary drivers already provide a fingerprint in the log file as it is now. There are many other "signs" that a log file can show to a developer in this regard already too. So, to see if someone is running X and using a proprietary driver, simply look at the driver name, and other data present in the log file. >Likewise an XFree86 problem with NVidia's binary drivers is >probably not anything that the XFree86 developers can fix >(except for Mark Vojkovich, of course :) ). Mark doesn't work on the proprietary drivers at Nvidia to my knowledge. He works on the "nv" driver though. I'm sure someone will speak up and correct me if I'm wrong on this assumption though. 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. The modules could be signed with a randomly generated key that changes every build, in order that nobody can later create modified modules that still show as signed. Or, it could use a static key, such as a vendor's GPG key. When the X server loads a module, it checks to see if it is digitally signed or not. If not, it logs to the log file "unsigned module foo". The stock sources could have this all disabled by default, and if module signing is enabled, have the server load all modules by default unless configured to have strict-signed-only-modules mode enabled. Vendors could then ship the X server with modules signed at build time. The X server would load modules and would display in the log file wether the modules were signed or not and if signed, if the signature matches one considered "good" or not. This would help a developer to know wether the user is using the modules that were supplied officially by the OS, or an update to the OS, or if the user is using a module they downloaded from somewhere or perhaps compiled themselves. Knowing that a user is using a *different* driver module than the one you're likely to assume they're using because you shipped it, can be the difference between night and day in solving a reported problem. Note that some people may read my idea above and assume some sort of "security" context out of the idea, or assume that I am refering to the signing of modules as being some security mechanism. When mentioning the GPG signing of modules to various people in the past, I've had people debate with me how this does not provide any real additional security guarantees. Just to avoid a repeat of such a discussion here now that I've voiced the idea again, let me say the following: I personally do not have any interest in the GPG signing of modules being used as a security mechanism, or to prevent unauthorized modules from being used in any form of security context. The entire idea is _purely_ based on a "developmental troubleshooting" context, which is to say that the signing and checking of module signatures is something that would show up in bug reports in log files, etc. and it would be useful data to know what module a user is using and where it came from. There is no guarantee that that information is secure, and that the user has not tampered with it, forged the signing info in the log file, or some other sleight of hand. If they did do so, they would only hurt themselves, and in the worst case - leave a developer in the same position we are now with unsigned modules. Signing the modules would result in *most* users submitting honest log files that are not tampered, and would provide more often than not - additional information about what the user is running. 3rd party vendors and developers could then even sign the modules that *they* release, and have the signature tested at load time as well. Again, it doesn't buy any security (IMHO), but the idea isn't intended for that, but rather intended for troubleshooting and with the assumption the user is honest and not dishonest. In this respect, GPG signing of modules would be similar in concept to the kernel's tainting flags. Always eager to hear other people's thoughts on this idea. Feel free to follow up with improvements, shoot-downs, suggestions, whatever. ;o) Take care, TTYL -- Mike A. Harris _______________________________________________ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
