Various privileges when executing a kernel module

I have two places in the kernel module (Linux 3.13):

  • One module_init
  • Another is the code that I use when I run an invalid operation code (according to the break-in interrupt description table).

My code is to enable a hardware performance counter. When I put it in module_init , the code works fine. But when I put it in second place (caused by running a command with an invalid operation code), the code receives a permission denied error (i.e. Errno: -13 ).

Since both places are in the same kernel module, is it true that "even in kernel space there are different privileges?"

Updates: it is worth mentioning that when I run an invalid operation code as root in user space, the error -13 absent; otherwise it stays ...

I assume that "the privilege of command execution solves the problem of executing the interrupt handler."

+5
source share
1 answer

Because module_init and your hook code work in different processes. And between different processes, there are different privileges.

Typically, the code should be executed in the process.

module_init always works during the period of the insmoding module (see the sys_init_module function). When you enter the kernel module, you must be root. And this process is also the root. So it works well.

But when you put the code in the IDT, it can run in the user process, as the user process triggers an interrupt. It happened -EPERM.

You can check euid, uid, pid and comm in your code. Like this:

 int hook_func() { printk(KERN_INFO"Code Called in hook_func. My pid: %d, comm: %s, uid: %d, euid: %d\n", current->tgid, current->comm, current->cred->uid, current->cred->euid); ... } int my_init() { printk(KERN_INFO"Code Called in my_init. My pid: %d, comm: %s, uid: %d, euid: %d\n", current->tgid, current->comm, current->cred->uid, current->cred->euid); ... } module_init(my_init); 
+2
source

All Articles