Re: no version magic, tainting kernel.

[Christian Zander]

On Thu, Jan 23, 2003 at 11:35:40AM -0800, Mark Fasheh wrote:
>
> Can't the stuff in init/vermagic.c be moved into a header file?
> Maybe vermagic.h? Most of the code can be cut 'n pasted right out of
> vermagic.c and the bit that defines "const char vermagic[]..." could
> be placed inside a macro which modules would then stick in the
> bottom of one of their c files.  This is what I'm getting at
> (warning I haven't checked this code or even tried to clean it up):
> 
> in vermagic.h:
> #include <linux/version.h>
> #include <linux/module.h>
> 
> /* Simply sanity version stamp for modules. */
> #ifdef CONFIG_SMP
> #define MODULE_VERMAGIC_SMP "SMP "
> #else
> #define MODULE_VERMAGIC_SMP ""
> #endif
> #ifdef CONFIG_PREEMPT
> #define MODULE_VERMAGIC_PREEMPT "preempt "
> #else
> #define MODULE_VERMAGIC_PREEMPT ""
> #endif
> #ifndef MODULE_ARCH_VERMAGIC
> #define MODULE_ARCH_VERMAGIC ""
> #endif
> 
> #define KERNEL_VERSIONMAGIC const char vermagic[]			\
> __attribute__((section("__vermagic"))) =				\
>        UTS_RELEASE " "							\
>        MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT MODULE_ARCH_VERMAGIC	\
>        "gcc-" __stringify(__GNUC__) "." __stringify(__GNUC_MINOR__)
> 
> 
> in my_external_module.c, and init/vermagic.c I'd just do:
> #include <linux/vermagic.h>
> KERNEL_VERSIONMAGIC();
> 
> and be done with it.
> 
> Modules that ship with the kernel wouldn't have to change a thing
> (and still be linked against vermagic.c, and it'd only add two lines
> of code to everyones externally shipped modules. I don't really
> think that this would be "doing too much" for those whose modules
> are included in Linus's kernel, and it wouldn't require people to
> keep entire source tree's around to compile a module or two...  Am I
> totally missing something here or wouldn't this solve our problem?
> Someone please correct me if I'm wrong :)
>

I wouldn't go as far as saying that the current solution imposes an
onerous requirement on any user wishing to build third-party modules
by relying on a complete and properly configured kernel source tree,
but it certainly seems like a step backwards from Linux 2.4, where
properly configured kernel headers are sufficient.

Of course, this only holds true for external projects using kbuild to
build the modules; other build systems would not only require that a
complete, configured kernel source tree be installed, they would also
rely on that source tree to be uncleaned since they have no knowledge
of how init/vermagic.o is to be built (and shouldn't make assumptions,
not considering possible legal/licensing implications). This I really
do consider an unnecessary, burdensome prerequisite.

Since I'm not intimately familiar with kbuild, I'm also wondering if
this scenario would be a problem:

Somebody downloaded Linux 2.5.59, configured it and built it using a
pre-3.0 version of gcc, e.g. gcc 2.95. The user had plenty of disk
space and decided, based on past experiences, that leaving the source
tree uncleaned is least likely to cause problems, should he/she ever
be intersted in building third-party modules. For some time, the user
placed no interest in external modules and used his/her system quite
happily; with the release of a new, improved version of a driver, the
user decided that he wants to give it a try, however, and built the
driver module, which picked up init/vermagic.o; our imaginary user is
using a distribution that provides frequent updates and he/she makes
regular use of this service - it just so happens that one of these
updates installed gcc 3.0 as the new default compiler. The new module
is thus built using gcc 3.0, but init/vermagic.o still indicates gcc
2.95; the module loader will erroneously believe everything is fine.

I agree with Mark that moving the code in init/vermagic.c into a new
header file like linux/vermagic.h is a better solution.

-- 
christian zander
[e-mail]