CLNP ( Connection Less Network protocol ) was present as a loadable kernel module in 2.6.17.3 linux version.
At that time it was not linked with Datalink layer and Application layer and so the project was not considered as complete.
The project of implementing CLNP was continued by the CLNP subteam of BPPT-SGU 2008 and the remaining work was also completed.
Here is the source code for it.
https://github.com/crazoes/clnp
INSTALL file gives the description about how we can load this particular module in 2.6.17.3 kernel as it has slight different process than other modules. https://github.com/crazoes/clnp/blob/test/INSTALL
My Question
I want to load this module on the current kernel version. Is this possible?
My ultimate goal is to anyhow get this module working on latest kernel version. But this doesn't seem to be possible without changing the code. I am assuming that I'll have to rework on the whole driver.
Because many of the header files which CLNP was using during 2.6.17.3 kernel version (example:- socket.h) has changed in lot of terms.
But still, I would like to know if there is any way possible to have this work done.
Related
I want to edit compiled kernel module file (module.ko) to insert something like "MODULE_INFO(vermagic, "3.10.9-blabla");" because this module file does not load with insmod and i get the error "failed (Exec format error)", the module was made for 2.6.35-smp version, I'm new to linux.
You cannot edit a compiled module directly.
Whatever change you need to do, you have to edit the source file and then compile it again.
From version 2.6.35 to 3.10 quite a lot of things changed; most likely the module is not compatible at all and it will not work. So, even if you can change the vermagic in the binary file it will not work because it's incompatible.
In your case, as Hector said, you have to recompile the module against a different Linux version. This process will also highlight all the incompatibilities that you should fix too.
If you do not have the sources because it is not an open source module: complain with the vendor :)
Although you will not be able to edit your compiled module now, build your kernel with CONFIG_MODVERSIONS is not set from next time, for driver development. It will enable you to make any number of incremental changes to your driver and load it against the newly built kernel with CONFIG_MODVERSIONS is not set.
CONFIG_MODVERSIONS is a notion thought up to make people's lives easier. If your kernel is compiled with CONFIG_MODVERSIONS=y, it enables you
to only be able to load modules that were compiled specifically for
that kernel version. Whereas, if your kernel is built with CONFIG_MODVERSIONS is not set, it will enable your driver to load on any kernel where CONFIG_MODVERSIONS is not set. You can modify this field in the .config file of your linux-kernel directory.
how can I obtain runtime information about which version of kernel is running from inside linux kernel module code (kernel mode)?
By convention, Linux kernel module loading mechanism doesn't allow loading modules that were not compiled against the running kernel, so the "running kernel" you are referring to is most likely is already known at kernel module compilation time.
For retrieving the version string constant, older versions require you to include <linux/version.h>, others <linux/utsrelease.h>, and newer ones <generated/utsrelease.h>. If you really want to get more information at run-time, then utsname() function from linux/utsname.h is the most standard run-time interface.
The implementation of the virtual /proc/version procfs node uses utsname()->release.
If you want to condition the code based on kernel version in compile time, you can use a preprocessor block such as:
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,16)
...
#else
...
#endif
It allows you to compare against major/minor versions.
You can only safely build a module for any one kernel version at a time. This means that asking from a module at runtime is redundant.
You can find this out at build time, by looking at the value of UTS_RELEASE in recent kernels this is in <generated/utsrelease.h> amongst other ways of doing this.
Why can't I build a kernel module for any version?
Because the kernel module API is unstable by design as explained in the kernel tree at: Documentation/stable_api_nonsense.txt. The summary reads:
Executive Summary
-----------------
You think you want a stable kernel interface, but you really do not, and
you don't even know it. What you want is a stable running driver, and
you get that only if your driver is in the main kernel tree. You also
get lots of other good benefits if your driver is in the main kernel
tree, all of which has made Linux into such a strong, stable, and mature
operating system which is the reason you are using it in the first
place.
See also: How to build a Linux kernel module so that it is compatible with all kernel releases?
How to do it at compile time was asked at: Is there a macro definition to check the Linux kernel version?
Thanks to every one,
This is the question asked in one of the interview i faced.
I have a Linux device driver which was compiled in Linux kernel version 2.6.I would like to port the same driver in a Linux PC which has kernel 3.X without compiling in new versions.
Is it possible ? If it is possible please let me know how. If it is not possible please let me know why not ?
Thanks & Regards
Siva
No you cannot port module which is compiled for one version to other version.
The reason is as follows
Modules are strongly tied to the data structures and function prototypes defined in a particular kernel version;
the interface seen by a module can change significantly from one kernel version to
the next. This is especially true of development kernels, of course
The kernel does not just assume that a given module has been built against the
proper kernel version. One of the steps in the build process is to link your module
against a file (called vermagic.o) from the current kernel tree; this object contains a
fair amount of information about the kernel the module was built for, including the
target kernel version, compiler version, and the settings of a number of important
configuration variables. When an attempt is made to load a module, this information
can be tested for compatibility with the running kernel. If things don’t match,
the module is not loaded; instead, you see something like:
# insmod hello.ko
Error inserting './hello.ko': -1 Invalid module format
A look in the system log file (/var/log/messages or whatever your system is configured
to use) will reveal the specific problem that caused the module to fail to load.
Kernel interfaces often change between releases. If you are writing a module that is
intended to work with multiple versions of the kernel (especially if it must work
across major releases), you likely have to make use of macros and #ifdef constructs
to make your code build properly.
now it's not possible:
usually, a "driver" is a binary kernel-module
porting will involve code-changes to the kernel module. if you change the code, you need to compile it, in order to get a binary.
since kernel modules run in kernel space, it is crucial that they are robust. since parts of the kernel-API change every now and then, trying to use a module compiled for kernel-X with another kernel-Y, might either not load because of missing symbols (if you are lucky) or lead to a kernel panic because semantics have changed.
btw, all this is not really related to 2.6.x vs 3.y, but holds true for any kernel version
but then: of course in theory it is possible to "write" a kernel-module as binary code in your favourite hex-editor, without resorting to compilers and such. this would allow you to "port" a driver from one kernel to another without recompilation. i guess this is not for humans though...
I am working on detecting kernel level rootkits and have chosen Adore-Ng as my first test rootkit. After having known how this rootkit hides itself and other processes in the Linux kernel (2.4, 2.6 versions), I now want to know how it gets loaded into the kernel.
Specifically, I want to know whether
1. It calls any already existing APIs in the Linux kernel OR
2. Does it have any hard-coded assembly instructions such that as soon as its compiled, it gets loaded into the kernel?
I went through the source code of Adore-Ng but couldn't find anything in this direction and could only see how it achieves its goal of hiding.
Can anyone tell/suggest how I can find its loading behaviour?
Thanks.
The core of the Adore rootkit is a malicious module, so for it to be loaded into the kernel you first need root access, then run insmod (or modinfo).
Another way to load Adore is to infect a trusted kernel module as described in Phrack volume 0x0b, issue 0x3d. It wouldn't be as stealthy as the former way because the cleaner module wouldn't be invoked. Since you went through the source code, I believe you have the aptitude to modify the source to invoke the cleaner module once the Adore module has infected a legit module. (make sure you also leave no trace of the module infection; the cleaner will not pick that up).
Any admin worth his salt would use signed modules, so don't expect these methods to work on production kernels after the 2.6 mainline.
Is it possible to upgrade only a specific sub-system, say I2C, of the Linux Kernel.
For example:
Is it possible to include "Support for multiplexed I2C bus topologies (introduced in Kernel 2.6.36)" in the Kernel version 2.6.31.1.
No this is not possible.
A kernel module or 'subsystem' (eg the i2c module) is build for a specific kernel image, you cannot combine different kernel(module) versions.
If you are feeling lucky (depending on your kernel skills), you could:
download the source code of your kernel
Install compiler and friends
add the updated ic2 driver
Try to compile the module for your kernel version
Cross your fingers and load it into your own kernel...\
I do not have any experience with this, so I do not know whether this works or not. Of course, if the ic2 module requires other (updated) modules, you could be ending up with updating (almost) the complete kernel...