The return of modversions
Kai Germaschewski has posted a modversions implementation which works with recent 2.5 kernels. The underlying idea is essentially the same as that found in previous implementations, but the implementation is entirely different.
The old scheme used the genksyms program to generate the checksums, and to create a bunch of include files (ending in .ver) which redefined the exported kernel names to include those checksums. The effect was to create a bunch of preprocessor definitions like:
#define printk printk_R1b7d4074
(The actual definitions were a little more complicated). Loadable modules would thus be built to call printk_R1b7d4074() instead of printk(). The names were stored in that form in the kernel symbol table, so the insmod program simply needed to look for a direct match. If the interface had changed, the names would not match, and the module would refuse to load.
The new implementation does away with the include files. It does
still use genksyms, but the output is reprocessed into a set of
structure declarations. One structure (containing the symbol name and its
checksum) is created for each symbol used by the module; the array of
structures is then linked into the module in a special section. When a
module is loaded into the kernel, the checksums are used to verify
compatibility, and the special section can be discarded. Among other
things, this approach makes it easier to force the loading of a module with
mismatched symbols, should anybody be unwise enough to attempt such a thing.
Posted Jan 30, 2003 18:45 UTC (Thu)
by Ross (guest, #4065)
[Link] (1 responses)
If so, this is going to be really nice. People won't be forced to use a kernel compiled with modversions just because they are using a binary-only module with symbol versions. Nor will distribution kernels be unable to load unversioned modules.
Posted Jan 31, 2003 0:55 UTC (Fri)
by TheOneKEA (guest, #615)
[Link]
LYS, it would make one of nVidia's headaches go away, and it would make distro building much easier.
Posted Feb 2, 2003 3:50 UTC (Sun)
by wolfrider (guest, #3105)
[Link] (1 responses)
--Is it just me, or does this strike anyone else as a potential problem? 1. Root is the only one that can/should load modules --Please feel free to correct / educate me here...
Posted Feb 2, 2003 5:05 UTC (Sun)
by Ross (guest, #4065)
[Link]
Posted Feb 5, 2003 15:52 UTC (Wed)
by mwilck (subscriber, #1966)
[Link]
A RedHat-centric point of view. SuSE/UnitedLinux does not use modversions (I don't think they SuSE ever has). Binary modules usually come with a wrapper that is available as source code and completely encapsulates the binary part. That is, from the modversioning point of view, there is no difference between a native kernel module and a "binary" module. What makes binary modules incompatible between RedHat kernels is the kernel release compiled into the version string. Yes, it can be circumvented with insmod -f, but who would use that in a production system? Btw the release in the version string is a good thing; it is nice to know your kernel exactly just by an "uname -r". Always talking of production systems here.
Posted Feb 6, 2003 21:51 UTC (Thu)
by mmarq (guest, #2332)
[Link] (3 responses)
Is it incompatible with the structure of the kernel, or the modular ELF data format???????? IMHO a kernel LSB kind of interface, is the thing that makes most sense and is most missed in the kernel... If i sayed something stupic, then is stupid or not that, when something more deep changes in the kernel you have to fix all the drivers, mostly for hardware that have not changed!!!!...and if you consider a development serie takes 2 years, than it probably means that in 50% of the cases you are fixing drivers for hardware that is no longer produced for at least 1 year!!!???? This is the worst case of ineficiency that i have ever saw in IT industry!!!!
Posted Feb 7, 2003 1:04 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (2 responses)
It goes to the heart of Linux philosophy that there are many variations of Linux available and even within one development stream, developers do not constrain themselves with backward compatibility. Linux is not like commercial software products. I have a great anecdote about the difference. I developed a filesystem driver as a loadable kernel module for Linux and an equivalent one for AIX. With Linux, I had to do some nontrivial recoding several times to make it work with the latest 2.4 kernel or with someone else's variation on 2.4. With AIX, I loaded the module that was written for, compiled for, and tested on an AIX 4.3.3 32 bit UP system into an AIX 5.1 64 bit MP system. It worked fine. AIX 5.1 has a lot of improvements over 4.3.3 in the filesystem driver interface, but none of them broke binary compatibility. This and related issues mean there will probably be a lot more people using the AIX implementation of this technology than the Linux one. --
Posted Feb 8, 2003 1:08 UTC (Sat)
by mmarq (guest, #2332)
[Link]
Also, i belive that you can agree with me that, this some how burocratic big work mean that you have to restrict a bit how the kernel is developed!... "that is why Linux is not like a commercial software product"... you can go absolutely wild with the changes implemented!!!... BUT IN THE END THERE IS POSSIBLY NO ALTERNATIVE TO THIS TRADEOFF OF SOME DEVELOPING RESTRICTIONS FOR STANDARDS Even that stubborn maniac "big" person, RMS(someone who we have many things to thank for:- [now i'm gonna be flamed to smoke])have learned by now that there is no effective way to control the "hardware industry"...is like playing chicken with high speed vehicles, and the hardware industry due to various reasons including its nature, has no way for turning!... The danger for Linux due to his wilderness, is of running almost everywhere now, to running almost nowhere in some distant forseenable future... it adapts and overcome or it dies... it is clear that the MS Palladium project is "whoped" to function like one big of many among others of hardware platform lock up attempts. Cutting on the politics, and to tell you the true, my original idea was that "most if not all" of hardware drivers in linux kernel could adopt some form of I2O model, that is already in kernel(no need for brand new design at all), but without the need for special hardware,...and most likely also without the need for loadable kernel modules for the actual "low level in kernel space" hardware driver. The I2O model that is somehow well documented, is "independent" of hardware platform and OS implementation, and is the most advanced driver model that i ever saw in a technical paper, and in such a way, that the same driver could be used in LINUX, AIX, AS390, SOLARIS, HP-UX, (you name it), only need a recompile!!! NO WONDER that microsoft and Intel wore among the original prime backers, that suddenely drop it in the deep ocean!...the much cheaper WINTEL model was about to conquer the world!!! IMHO that with a I2O model, a corporation like IBM can have a high degree of sucess in the integration parts (Mobos, Graphics and Network adapters,.. etc), even wihtout a x86 compatible platform (use Linux anyway)...and wihtout the need to sell it's Hard Disk division,...as it seems!!!
Posted Feb 9, 2003 3:00 UTC (Sun)
by mmarq (guest, #2332)
[Link]
But i,m pretty sure that the IBM Almaden Research Center has the talent, and perhaps the will to invest in such a feat. ...althoug, and since the 2.5 model has evolved for grouping devices into classes, why not???...document into standars the "alwoed" calls involved, per classes, and in such a way that the printk()(example)will always be what a loadable module could expect, and avoid since the use of schemes like modversions.
Does this means that versioned modules and non-versioned modules will be identical except for the table of symbol versions?The return of modversions
I hope is the way it's implemented. That way you can add a kernel config option (CONFIG_MODVERSIONS_ALLOW_IGNORE) that will let you run insmod with, say, the --strip-modversions option, so that versioned modules could be used with unversioned kernels.The return of modversions
>> Among other things, this approach makes it easier to force the loading of a module with mismatched symbols, should anybody be unwise enough to attempt such a thing.The return of modversions
2. Modules with mismatched symbols act unpedictably(?)
3. This fix sounds like modules will have (at least a temporary) higher memory-usage requirement than 2.4.
Sometimes you know that a version mismatch doesn't matter. Yes, it is rare... it is much more likely that a version mismatch would cause unpredictable problems. But since root is the only one that can do this I don't see any problem. It is nice to get a warning if you do it by accident, but I hate arbitrary restrictions on root.
The return of modversions
> Production kernels shipped by distributors need this feature, however; The return of modversions
> otherwise it is essentially impossible for vendors to supportbinary-only
> modules.
Is it possible or not to use an API/ABI(in kernel space) kind of interface for the kernel drivers "problem"??????The return of modversions
If anyone can answer to this all, i'll be much aprecited.
The problem is, i think:!!
Why use an intermediary structure scheme, to bypass the GPL limitations, to call (example) printk() when you can call it directly???!!!.
Better!!... if you allow, any way, to use a specific interface to use kernel symbols why not group these in well documentaded API/ABI, that can be used for binary and or source modules???
I think you're proposing that instead of having complicated, imperfect mechanisms to be sure your base kernel has the same printk() that your loadable module expects, just have one standard, documented printk().regular ABI vs modversions
Bryan Henderson
IBM Almaden Research Center
San Jose CA
bryanh@almaden.ibm.com
Without wanting to quote any part we can assume that you thing that some kind of well documented "compatibility" interface is not only possible but also very desirable!...regular ABI vs modversions
Well, about the I2O idea i dont have real code, only some simple "sketches"!!...very soon the "thing" revealed itself as being way,...way over my head, even considering going heavy on cut and paste, and even considering that the idea was to use the already in kernel I2O implementation, and build a simple virtual machine "under the kernel" to simulate a central IOP, (I/O Processor) as specified in V2_spec in www.inteligent_IO.com!!!...regular ABI vs modversions