"Segmentation fault" when `rmmod` or `modprobe -r` - c

Trying the simplest kernel module from LDD3 without any modification on custom built kernel v4.1.0-rc6 for Beagle Bone board with BusyBox v1.23.0. The code for the module is as follows:
#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 Makefile is:
ARCH := arm
CROSS_COMPILE := arm-cortex_a8-linux-gnueabi-
obj-m := hello.o
all:
make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C /path/to/linux/source/tree M=$(PWD) modules
clean:
make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C /path/to/linux/source/tree M=$(PWD) clean
The module is compiling and installing on the rootfs just fine. also it is loading:
$ insmod hello.ko
[ 30.692404] Hello, world
But when trying to remove it, I am getting:
$ rmmod hello.ko
Segmentation fault
$modprobe -r hello.ko
Segmentation fault
$ lsmod
hello 813 0 - Live 0xbf000000 (O)
The kernel is compiled with module unloading (both regular and forced) support enabled.
What can be the possible cause of this issue? What is the way to approach the investigation of it?
Update:
As suggested in the comments I have tried including linux/kernel.h, defining the MODULE,LINUX and __KERNEL__ symbols. Added the__init and __exit prefixes to the functions. Removed the static modifiers. Removed the printk lines. The result the same. dmesg shows only the initial greeting. Loading and unloading of the kernel's modules such a gpio_keys or crypto/ccm is working, surprisingly. So the only thing remaining to suspect is the way the module is compiled..
Update 2
Updating the kernel to the freshest snapshot didn't help. Compiled the module with different optimization settings didn't help. Next step, I guess, I am going to modify the BusyBox's rmmod to have some indication of the problem location..

Have a look at these tutorials:
http://www.tldp.org/HOWTO/Module-HOWTO/x839.html
http://www.tldp.org/LDP/lkmpg/2.4/html/x281.htm
Try adding:
#define MODULE
#define LINUX
#define __KERNEL__
#include <linux/kernel.h> /* Needed for KERN_ALERT */

I have managed to work around this problem. Using strace I've found out that the segfault is occurring somewhere when reading the BusyBox specific modules.dep.bb file. This file is used by BusyBox when it is compiled with the "Simplified modutils" option (CONFIG_MODPROBE_SMALL). By disabling the option, selecting the utils to be installed and rebuilding BusybBox I've got the module unloading work. I believe the problem root is near the fact the test module is compiled and stored outside the /lib/..../modules directory, so busybox with the simplified modutils is just getting confused.

Related

Does Writing Linux Kernel Module Require Compiling Own Kernel?

I have a simple hello world kernel module on Ubuntu x86_64:
#include <linux/module.h>
static int
mod_init(void)
{
printk(KERN_INFO "RYANhello world\n");
return 0;
}
static void
mod_exit(void)
{
printk(KERN_INFO "RYANgoodbye world\n");
}
MODULE_LICENSE("GPL");
module_init(mod_init);
module_exit(mod_exit);
Makefile:
KERNEL_DIR := /lib/modules/$(shell uname -r)/build
CUR_DIR := $(shell pwd)
obj-m := module.o
default:
$(MAKE) -C $(KERNEL_DIR) M=$(CUR_DIR) modules
When I sudo insmod module.ko I get insmod: ERROR: could not insert module module.ko: Invalid parameters. Inspecting dmesg:
loading out-of-tree module taints kernel
module verification failed: signature and/or required key missing - tainting kernel
Repeating insmod yields module is already loaded however /var/log/syslog shows no trace of it loading (i.e printk messages not present). Also, running sudo rmmod module.ko:
rmmod: ERROR: ../libkmod/libkmod-module.c:1941 kmod_module_get_holders() could not open '/sys/module/module/holders': No such file or directory
rmmod: ERROR: Module unloading is not supported
This seems to indicate it's not loaded, even though dmesg says it is?
Addressing common issues; my host kernel and gcc version are the same as ones I compiling with.
So, this leads me to think that the module not being signed is the issue. To disable this do I have to compile and install my own kernel with appropriate .config? In other words, to write and test your own kernel modules on a modern GNU/Linux OS with enforced signing, do you have to compile and install your own kernel?
EDIT
CONFIG_MODULE_SIG_FORCE is not set in my /boot/config-5.8.0-53-generic, so it seems I should be able to load my module albeit with a tainted kernel message. So, why would I be getting Invalid parameters?
Inspecting dmesg on first insmod it was saying that the module was already loaded. As I had never loaded this before, this prompted me to think that this name was already taken.
Low and behold, renaming module.c/module.o --> example.c/example.o fixed the problem. The invalid parameters message was what threw me.

Initialization and Cleanup are swapped around in Kernel Module

Currently studying kernel modules, and we tasked with writing a small Hello World / Bye World kernel module (in C). Got the idea pretty quick and had a rough idea of what I should do.
Needed to make the initialization function print a Hello message, and the clean up function to print a Bye message. The initialization message should print when I add the kernel module to the list of modules (working on a Debian VM) using insmod, and the cleanup message should print when I remove the module using rmmod.
Here is a snippet of the code:
#define MODULE
#define LINUX
#define __KERNEL__
#include <linux/module.h> // all modules
#include <linux/kernel.h> // KERN_ALERT and potentially other priorities
#include <linux/init.h> // macros
static int __init do_initialization(void) {
printk(KERN_ALERT "Hello World :)");
return 0;
}
static void __exit do_cleanup(void){
printk(KERN_ALERT "Bye bye :)");
}
module_init(do_initialization);
module_exit(do_cleanup);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("A");
MODULE_DESCRIPTION("Exercise");
MODULE_VERSION("1.00");
This is the Makefile I use (this was provided to us but I understand most of it):
obj-m += mymodule.o
all:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
NB: I use KERN_ALERT instead of KERN_INFO just to make sure that it displays on my terminal regardless.
My problem lies in the following:
When I run insmod mymodule.ko, the Bye Bye message is printed. When I run rmmod mymodule.ko, the Hello message is printed. It really doesn't make any sense to me, and I made sure that my functions are correctly set inside the macros.
Any help is appreciated.
As indicated by the link that Tsyvarev added as a comment to the question on 1st March 2021, and by the answer by Roi on 2nd March 2021, I simply needed to add \n when logging the kernel. Thank you to everyone who helped.

How to compile / link / build a small sized Loadable Kernel Module ( LKM )?

I successfully built this trivial LKM with gcc but the resulting binary is of size 70kB.
#include <linux/init.h>
#include <linux/module.h>
MODULE_LICENSE("GPL");
static int __init LinuxKernelModule_init(void)
{
printk("LinuxKernelModule: Hello, world!\n");
return 0;
}
static void __exit LinuxKernelModule_exit(void)
{
printk("LinuxKernelModule: Goodbye, world!\n");
}
module_init(LinuxKernelModule_init);
module_exit(LinuxKernelModule_exit);
What CFLAGS and make arguments would you suggest to make it smaller?
The standard Linux kernel is compiled in an optimal way already unless it's a debug version or some very specific options are turned on. So the simplest Makefile for an external kernel module which doesn't add any compiler of linker options on top of those used to build the kernel should be sufficient and should produce an optimal kernel module.
For this trivial LKM (let's call it lkm.c) the simplest Makefile below produces a kernel module that is 3986 bytes in size on my system. gcc version is 7.4.0, ldd version is 2.27, the kernel is 4.15.0-66-generic, the distro is Ubuntu.
KERNEL = /lib/modules/$(shell uname -r)/build
obj-m += lkm.o
all:
${MAKE} -C ${KERNEL} M=$(PWD) modules
clean:
${MAKE} -C ${KERNEL} M=$(PWD) clean
Try to just make Makefile with following contents:
obj-m += test.o
and rename your module to test.c in the same directory.
Then make the module:
make -C /usr/src/linux M=`pwd`
and tell us what is the size of your output .ko file.
It is also possible that your .config of the kernel has enabled debugging symbols and it increases size of your module.

Loadable kernel module not compiles correctly on different computers

I'm trying to make loadable kernel module for ARM achitecture. Just for example I'm made simple hello.c
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
static int __init hello_start(void)
{
printk(KERN_INFO "Loading hello module...\n");
return 0;
}
static void __exit hello_end(void)
{
printk(KERN_INFO "Goodbye Mr.\n");
}
module_init(hello_start);
module_exit(hello_end);
And created Makefile
obj-m := hello.o
PWD := $(shell pwd)
ARCH=arm
CROSS_COMPILE_LINARO=/home/cooperok/mk908/gcc-linaro-arm-linux-gnueabihf-4.7-2013.01-20130125_linux/bin/arm-linux-gnueabihf-
KERNEL_ROCKCHIP=/home/cooperok/mk908/kernel/
default:
make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE_LINARO) -C $(KERNEL_ROCKCHIP) M=$(PWD) modules
clean:
make CROSS_COMPILE=$(CROSS_COMPILE_LINARO) -C $(KERNEL_ROCKCHIP) M=$(PWD) clean
Cross compiler and kernel sources are the same on both computers. When I'm running make on first machine compiled hello.ko file is successfully installed with insmod command, but when I'm compiling module on second machine and trying to install that module I'm getting error "insmod: error inserting 'hello.ko': -1 Invalid module format"
As I understand module is compiling with crosscompiler which I'm specified in CROSS_COMPILE (arm-linux-gnueabihf-gcc and others) and only it will make module without any specific libraries installed on computers, is it?
First computer have 64bit OS (Ubuntu 12.04), and second 32bit OS (Linux Mint 12), this is main difference, so make util is different. But is it realy main reason why module correctly compiling only on 64bit OS? If so is it problem in make, or it's really deals with different libraries?

No output to terminal after inserting a module with insmod

I am following the following tutorial, trying to learn how to develop device drivers, and in Chapter 2, the focus is to develop a working module and insert it into the kernel. I used the following code (hello.c):
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.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);
And my this is the Makefile:
obj-m += hello.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
I then run the following in LXTerminal:
brian#brian-desktop:~/driver_stuff/hello$ su
root#brian-desktop:/home/brian/driver_stuff/hello# make
make -C /lib/modules/2.6.32-21-generic/build M=/home/brian/driver_stuff/hello modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-21-generic'
Building modules, stage 2.
MODPOST 1 modules
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-21-generic'
root#brian-desktop:/home/brian/driver_stuff/hello# insmod ./hello.ko
root#brian-desktop:/home/brian/driver_stuff/hello# rmmod hello
root#brian-desktop:/home/brian/driver_stuff/hello# exit
However, after the insmod ./hello.ko command, one should expect that the terminal would print "Hello world!" and then "Goodbye, cruel world!" after the rmmod hello command. The book mentioned that this happens when you run the commands in the console, but not in an emulated terminal, could this be the problem?
I also checked under /var/log/messages and /var/log/messages.1 which had no record of either "Hello World!" nor "Good bye, cruel world!". Is it possible that these messages are in a different file, or is the issue that the messages aren't being pushed to the kernel in the first place?
If you need an info about the kernel I am running (Lubuntu 10.04, inside a VM):
brian#brian-desktop:~/driver_stuff/hello$ uname -r
2.6.32-21-generic
Thank you.
The output from kprintf is always to the kernel log. This may happen to also go to the system console (and, therefore, to the terminal you're using if you're on the console), but there's nothing to link it back to the specific terminal that you loaded the module in.
To read the kernel log, run dmesg.

Resources