Different privileges in kernel module execution

Question

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

1. One is module_init
2. The other is code I hook with running an invalid opcode (by hacking interrupt description table).

My code is to enable hardware performance counter. When I put it in module_init, the code works fine. But when I put it to second place (triggered by running an instruction with an invalid opcode), the code gets a permission denied error (i.e. errno:-13).

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

Updates: something that is worth to mention is that when I run the invalid opcode as root in user space, the -13 errno is gone; otherwise, it stays...

I speculate that "the privilege of an instruction execution decides that of its interrupt handler's execution."

Answer 1

Because module_init and your hook code running in different process. And there are different privileges between different process.

Generally, code must running in a process.

module_init always running in the period of insmoding module(See the sys_init_module function). When you insmod a kernel module, you must be a root. And the process is root too. So it running well.

But when you put the code in the IDT, it may running in a user process since a user process trigger a interrupt. So it got a -EPERM.

You can check the 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);