Adding Interrupt service routine in kernel - c

I am trying to add a switch/GPIO interrupt. I want to write it as part of kernel source tree. After building the kernel image and deploying to my custom board it has to appear in proc/interrupts. I have already written the module and it is working if do insmod. Instead of compiling separately i want it to be a part of my kernel tree.
What are the steps to add the irq to kernel source.

Actually if you have written the module inside the kernel tree, it is pretty straightforward:
Lets say you put the source code in drivers directory, so the hierarchy looks as follows:
drivers/hello
Kconfig
Makefile
hello.c
In drivers/Makefile you should add the following:
obj-$(CONFIG-HELLO) += hello/
In drivers/Kconfig you should add the following:
source "drivers/hello/Kconfig"
Sample code for drivers/hello/Kconfig:
config HELLO
tristate "Hello world module"
default n
help
Enable Hello world module support
Sample code for drivers/hello/Makefile:
obj-$(CONFIG_HELLO) += hello.o
Sample code for drivers/hello.c:
#include <linux/module.h>
#include <linux/moduleparam.h>
...
...
static int __init hello_init(void)
{
...
}
static void __exit hello_exit(void)
{
...
}
module_init(hello_init);
module_exit(hello_exit);
MODULE_AUTHOR("Obi One Kenoby");
MODULE_DESCRIPTION("Hello Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION("1.0");
Now you should be able to see the hello module in make menuconfig - select 'm' for module and '*' for built in. the module_init/module_exit macros works with both options.

Related

Unknown symbol when loading a kernel module

I tried to redo the code of the kernel module found in this topic How can I obtain battery level inside a Linux kernel module?. But when I try to use the functions contained in the power_supply.h header file, the loading of the module fails because it does not recognize the power_supply_get_by_name function.
Here is the code that I am using on Ubuntu 18.04 with kernel version 4.15.0-101-generic:
#include <linux/module.h>
#include <linux/power_supply.h>
static int __init test_init (void)
{
struct power_supply *psy;
char name[] = "BAT1";
psy = power_supply_get_by_name(name);
printk(KERN_DEBUG "Test module inserted");
return 0;
}
static void __exit test_exit (void)
{
printk(KERN_DEBUG "Test module removed");
}
module_init (test_init);
module_exit (test_exit);
I get no error at compiling except a warning concerning the module license which is I think not related to my problem but I get the following errors:
when running insmod in the terminal: "insmod: ERROR: could not insert module test.ko: Unknown symbol in module"
in the /var/log/kern.log file: "test: Unknown symbol power_supply_get_by_name (err 0)"
I checked the kallsyms proc file and the function is indicated as usable in other kernel modules if I understood well this topic What is the difference between T and t in /proc/kallsyms. Here is the output from reading the kallsyms file:
ffffffff8e9bd270 T power_supply_get_by_name
Does anyone knows why this is not working while I can use other linux headers functions without any problem and, if so, how I can fix my problem?
Thanks in advance
This may actually be related to the module license! If you look at the kernel source code, the function power_supply_get_by_name is exported here. You can see it's using EXPORT_SYMBOL_GPL. As this answer explains:
EXPORT_SYMBOL_GPL will show the symbol only in GPL-licensed modules
The use of this macro is controversial, but that's the way the project operates... To gain access to the symbols you need, you'll need to license your module as GPL:
MODULE_LICENSE("GPL");

Linux kernel module development buildroot

I have build a Linux kernel for the beaglebone black using buildroot. Now I would like to develop a hello world Linux kernel module application:
#include <linux/init.h>
#include <linux/module.h>
MODULE_LICENSE("Dual BSD/GPL");
static int hello_init(void)
{
printk(KERN_ALERT "Hello, world\n");
return 0;
}
static void hello_exit(void)
{
printk(KERN_ALERT "Goodbye, cruel world\n");
}
module_init(hello_init);
module_exit(hello_exit);
The problem is I still keep missing some header files. After finally gathering them all, I get an error that the code is not compilable (many errors, I don't want to paste them all). What I was wondering is either I am really including the right files?
At the moment I have:
/home/lukasz/brl/Machine/beaglebone/build/linux-headers-a75d8e93056181d512f6c818e8627bd4554aaf92/include
/home/lukasz/brl/Machine/beaglebone/build/uboot-2018.01/arch/x86/include
/home/lukasz/brl/Machine/beaglebone/build/linux-headers-a75d8e93056181d512f6c818e8627bd4554aaf92/arch/arm/include/generated
/home/lukasz/brl/Machine/beaglebone/build/linux-headers-a75d8e93056181d512f6c818e8627bd4554aaf92/arch/arm/include
/home/lukasz/brl/Machine/beaglebone/build/linux-a75d8e93056181d512f6c818e8627bd4554aaf92/include
Its a bit odd to me that the C include files and asm files are so scattered around within the directory. Are there some mistakes in my understanding of the topic here?
My Linux version:
# uname -a
Linux buildroot 4.9.59 #1 SMP Fri Oct 5 11:55:54 CEST 2018 armv7l GNU/Linux
To compile a kernel module, you need the real kernel sources, not just the kernel header files. You have to build from the kernel source directory with M= pointing to the source of your modules. And together with your module source, you of course also need a working Makefile. These steps are explained in any of the dozens of how-to-write-a-kernel-module guides, e.g. this one.
For cross-compilation, you also need to pass the appropriate arguments so that the kernel knows for which architecture to build and which cross-compiler to use. At the very least, this means you have to give the ARCH= and CROSS_COMPILE= options when building. Sometimes you need additional options (e.g. to point to the appropriate depmod tool).
To simplify this, Buildroot offers kernel module infrastructure. In the simplest case, you can just create a Config.in file containing
config BR2_PACKAGE_HELLOMOD
bool "hellomod"
depends on BR2_LINUX_KERNEL
and a hellomod.mk file containing
HELLOMOD_SITE = /path/to/hellomod/source
$(eval $(kernel-module))
$(eval $(generic-package))
You also have to source the Config.in from package/Config.in in the Buildroot tree. Or better yet, use an external tree so you don't have to modify Buildroot itself.

Could I find all kernel modules that are running even they are hide?

I am starting to develop kernel modules and I wonder about all methods to know which modules are running in order to remove them (include modules that they are hide).
E.g. The following module has two lines in order to hide him. (It is a typical rootkit development trick)
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
MODULE_LICENSE("GPL");
int example_init(void);
void example_exit(void);
module_init(example_init);
module_exit(example_exit);
int example_init(void) {
list_del_init(&__this_module.list); // Deletes entry from list and reinitialize it
kobject_del(&THIS_MODULE->mkobj.kobj); // Unlink kobject from hierarchy
printk("Example: module loaded\n");
return 0;
}
void example_exit(void) {
printk("Example: module removed\n");
}
When a module is loaded you can see the information with dmesg, lsmod, modinfo, modprobe, /proc/modules, /sys/module or /proc/kallsyms
My question is if exist ways to know (and remove) this module? obviusly, rmmod doesn't work because this module doesn't appear in /proc/modules list.

Writing a built in object for Linux Kernel?

Everywhere I search for Linux Kernel Development, I get answers for creating Linux Kernel modules.
Example
/*
* hello−1.c − The simplest kernel module.
*/
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
int init_module(void)
{
printk(KERN_INFO "Hello world 1.\n");
/*
* A non 0 return means init_module failed; module can't be loaded.
*/
return 0;
}
void cleanup_module(void)
{
printk(KERN_INFO "Goodbye world 1.\n");
}
Here, there is init_module and cleanup_module functions which i understand contains things to be executed when the kernel is initialized and cleaned up.
There are made by adding
obj-m += hello-1.c
to the makefile.
But I dont want this. I want to add a built in program, not a driver, basically a service to facilitate cloud uploading of some data from the kernel level. I dont event want the module option for the program when compiling the kernel.
I understand for just programs I should use obj-y not obj-m. But there is no manual to write these kind of programs. Why? Am I missing something? Does these programs also have the init_module and cleanup_module functions even though they are not modules?
For example consider that your source is under driver/new in the linux kernel source tree.
You need to modify Makefile's under drivers and new to build your module statically into linux kernel.
Under drivers/Makefile add the below line at the end.
obj-y += new/
Under drivers/new/Makefile add the below line at the end.
obj-y += hello.o
After build the linux kernel. And load to see that your module has printed the printk messages using dmesg command.
Note: When building module statically into linux, change
int init_module(void)
to
int __init init_module(void)
and change
void cleanup_module(void)
to
void __exit cleanup_module(void)
Look into kernel doc Makefiles
Refer:
"
--- 3.2 Built-in object goals - obj-y
The kbuild Makefile specifies object files for vmlinux
in the $(obj-y) lists. These lists depend on the kernel
configuration.
Kbuild compiles all the $(obj-y) files. It then calls
"$(LD) -r" to merge these files into one built-in.o file.
built-in.o is later linked into vmlinux by the parent Makefile.
The order of files in $(obj-y) is significant. Duplicates in
the lists are allowed: the first instance will be linked into
built-in.o and succeeding instances will be ignored.
Link order is significant, because certain functions
(module_init() / __initcall) will be called during boot in the
order they appear. So keep in mind that changing the link
order may e.g. change the order in which your SCSI
controllers are detected, and thus your disks are renumbered.
Example:
#drivers/isdn/i4l/Makefile
# Makefile for the kernel ISDN subsystem and device drivers.
# Each configuration option enables a list of files.
obj-$(CONFIG_ISDN_I4L) += isdn.o
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
"

How to call exported kernel module functions from another module?

I'm writing an API as a kernel module that provides device drivers with various functions. I wrote three functions in mycode.c. I then built and loaded the module, then copied mycode.h into < kernel >/include/linux. In a device driver, I have a #include < linux/mycode.h > and call those three functions. But when I build the driver module, I get three linker warnings saying that those functions are undefined.
Notes:
The functions are declared extern in mycode.h
The functions are exported using EXPORT_SYMBOL(func_name) in mycode.c
Running the command nm mycode.ko shows all three functions as being available in the symbol table (capital T next to them, meaning the symbols are found in the text (code) section)
After loading the module, the command grep func_name /proc/kallsyms shows all three functions as being loaded
So clearly the functions are being exported correctly and the kernel knows what and where they are. So why can't the driver see their definitions? Any idea what am I missing?
EDIT: I found some information about this here: http://www.kernel.org/doc/Documentation/kbuild/modules.txt
Sometimes, an external module uses exported symbols from another
external module. kbuild needs to have full knowledge of all symbols
to avoid spitting out warnings about undefined symbols. Three
solutions exist for this situation.
NOTE: The method with a top-level kbuild file is recommended but may
be impractical in certain situations.
Use a top-level kbuild file If you have two modules, foo.ko and
bar.ko, where foo.ko needs symbols from bar.ko, you can use a
common top-level kbuild file so both modules are compiled in the
same build. Consider the following directory layout:
./foo/ <= contains foo.ko
./bar/ <= contains bar.ko
The top-level kbuild file would then look like:
#./Kbuild (or ./Makefile):
obj-y := foo/ bar/
And executing
$ make -C $KDIR M=$PWD
will then do the expected and compile both modules with full
knowledge of symbols from either module.
Use an extra Module.symvers file When an external module is built,
a Module.symvers file is generated containing all exported symbols
which are not defined in the kernel. To get access to symbols from
bar.ko, copy the Module.symvers file from the compilation of bar.ko
to the directory where foo.ko is built. During the module build,
kbuild will read the Module.symvers file in the directory of the
external module, and when the build is finished, a new
Module.symvers file is created containing the sum of all symbols
defined and not part of the kernel.
Use "make" variable KBUILD_EXTRA_SYMBOLS If it is impractical to
copy Module.symvers from another module, you can assign a space
separated list of files to KBUILD_EXTRA_SYMBOLS in your build file.
These files will be loaded by modpost during the initialization of
its symbol tables.
But with all three of these solutions, in order for any driver to use my API, it would have to either create a new Makefile or have direct access to my Module.symvers file? That seems a bit inconvenient. I was hoping they'd just be able to #include my header file and be good to go. Do no other alternatives exist?
From my research, it seems that those are the only three ways to handle this situation, and I've gotten each of them to work, so I think I'll just pick my favorite out of those.
Minimal QEMU + Buildroot example
I have tested the following in a fully reproducible QEMU + Buildroot environment, so maybe having this working version version will help you find out what is wong with your code.
GitHub upstream is centered on the files:
dep.c
dep2.c
Makefile
dep.c
#include <linux/delay.h> /* usleep_range */
#include <linux/kernel.h>
#include <linux/kthread.h>
#include <linux/module.h>
MODULE_LICENSE("GPL");
int lkmc_dep = 0;
EXPORT_SYMBOL(lkmc_dep);
static struct task_struct *kthread;
static int work_func(void *data)
{
while (!kthread_should_stop()) {
printk(KERN_INFO "%d\n", lkmc_dep);
usleep_range(1000000, 1000001);
}
return 0;
}
static int myinit(void)
{
kthread = kthread_create(work_func, NULL, "mykthread");
wake_up_process(kthread);
return 0;
}
static void myexit(void)
{
kthread_stop(kthread);
}
module_init(myinit)
module_exit(myexit)
dep2.c
#include <linux/delay.h> /* usleep_range */
#include <linux/kernel.h>
#include <linux/kthread.h>
#include <linux/module.h>
MODULE_LICENSE("GPL");
extern int lkmc_dep;
static struct task_struct *kthread;
static int work_func(void *data)
{
while (!kthread_should_stop()) {
usleep_range(1000000, 1000001);
lkmc_dep++;
}
return 0;
}
static int myinit(void)
{
kthread = kthread_create(work_func, NULL, "mykthread");
wake_up_process(kthread);
return 0;
}
static void myexit(void)
{
kthread_stop(kthread);
}
module_init(myinit)
module_exit(myexit)
And now you can do:
insmod dep.ko
insmod dep2.ko
With that Buildroot setup, things are already configuring depmod /lib/module/*/depmod with the dependency, so just this is enough to load both:
modprobe dep
Also, if you built your kernel with CONFIG_KALLSYMS_ALL=y, then the exported symbol can be seen with:
grep lkmc_dep /proc/kallsyms
see also: Does kallsyms have all the symbol of kernel functions?
OK: You have one module where the function is and one place what wants to import it right?
You must use "EXPORT_SYMBOL("name of the function") such as foo in the place where the function is. So in the "c" file have the function "foo" defined and put in:
EXPORT_SYMBOL(foo)
Make sure you have the prototype for "foo" in a common header file (you can have it in separate places for each module and it will work but you are asking for trouble if the signatures change). So say: void foo(void *arg);
Then the other module that wants it just invoke "foo" and you are good.
Also: Make sure that you load the module with foo first. If you have cross dependencies like module2 needs foo from module1 and module1 needs bar from module2 you need to have one register functions with another. If you want to know please ask a separate Q.

Resources