How to Communicate with a Linux Kernel Module from User Space Without Littering /Dev with New Nodes

How to communicate with a Linux kernel module from user space without littering /dev with new nodes?

Netlink sockets are designed for that kind of requirements, too...

Also see

• man 7 netlink
• libnl - Netlink library
• The libnl Archives

Does Kernel to/from User Space Communication Need To Be Secured

My advice would be to rather do strict checking on the data received in the kernel. What is the attack scenario for falsifying information? The impact seems to be able to change temperatures or fan speeds, which is low enough that I do not see any reason to attack, unless another issue can be exploited - like buffer overflow in the kernel string handling etc. In that case, defending on the kernel side seems to be the correct protection, as it protects against malicious use of the user side program as well.

What is the best way to communicate a kernel module with a user space program?

Read some other modules that do what you want.

There are lots of options for how to do this in the Linux kernel, including:

• virtual filesystems, e.g. /proc, /sys, configfs, relayfs (really look at relayfs)
• netlink
• blocking syscalls
• poll() / epoll() & related

/proc is probably the easiest to start with since it has been around forever and there is a ton of documentation on how to use it. Create a virtual file that maps to your buffer, then have your userspace app open an fd and use select. Simple and ubiquitous. There are more modern and "better" ways - they will inevitably be described in terms of /proc + select() so learning those first will teach you something useful.

How can kernel module communicate with user-space process during rmmod?

Such a design does not fit well with how the kernel works.

Instead, you should make the module report itself as in-use until the cleanup has been completed (so causing rmmod to fail). When you want to unload the module, you should trigger the userspace cleanup to happen, then perform the rmmod when it is complete (presumably with some kind of userspace script).

You could implement this by having the userspace daemon hold a file descriptor open to the device provided by the kernel module, closing it once the userspace cleanup has happened.

Communicate Kernel module and user space (Driver)

First of all, you shouldn't check the return value of filp_open with NULL. You should check if the call has succeeded by using IS_ERR()

if (IS_ERR(f)) {
    pr_err("Error opening file")
}

I believe the file_open has returned an error pointer and you are trying to dereference it

f->f_op->read(f, buf, 128, &f->f_pos);

Alternatively, you can use addr2line to find which line has caused the kernel panic

---

Related Topics