Различные привилегии при выполнении модуля ядра

У меня есть два места в модуле ядра (Linux 3.13):

  1. Один module_init
  2. Другой - это код, который я перехватываю с запуском недопустимого кода операции (путем взлома таблицы описания прерываний).

Мой код должен включить счетчик производительности оборудования. Когда я помещаю его в module_init, код работает нормально. Но когда я помещаю его на второе место (вызванное выполнением инструкции с недопустимым кодом операции), код получает ошибку permission denied (т. е. errno:-13).

Поскольку оба места находятся в одном модуле ядра, правда ли, что «даже в пространстве ядра существуют разные привилегии?»

Обновления: стоит упомянуть, что когда я запускаю недопустимый код операции как root в пользовательском пространстве, ошибка -13 исчезает; иначе останется...

Я предполагаю, что «привилегия выполнения инструкции определяет привилегию выполнения обработчика прерывания».


person Richard    schedule 08.06.2015    source источник
comment
У вас всегда есть привилегии ОС на процессоре. Даже в режиме ядра; не все разрешено. В противном случае вы можете легко взять на себя управление.   -  person Willem Van Onsem    schedule 08.06.2015
comment
@CommuSoft: Объясняет ли это разницу между его кодом ядра в module_init и его кодом ядра для ловушки кода операции?   -  person Nemo    schedule 08.06.2015
comment
Я думаю, здесь очень поможет SSCCE.   -  person Nemo    schedule 08.06.2015
comment
@CommuSoft, вы говорите, что код обработчика (случай 2 в OP) работает в ядре, но с привилегиями, отличными от кольца 0?   -  person Richard    schedule 08.06.2015
comment
Некоторые функции ядра намеренно проверяют привилегии текущего пользователя. Для более подробного ответа обновите свой пост с помощью функции enable hardware counter и способа hacking interrupt description table.   -  person Tsyvarev    schedule 08.06.2015


Ответы (1)


Потому что module_init и код вашего хука работают в разных процессах. И есть разные привилегии между разными процессами.

Как правило, код должен выполняться в процессе.

module_init всегда работает в период установки модуля (см. функцию sys_init_module). Когда вы встраиваете модуль ядра, вы должны быть пользователем root. И процесс тоже root. Так что работает хорошо.

Но когда вы помещаете код в IDT, он может работать в пользовательском процессе, поскольку пользовательский процесс вызывает прерывание. Итак, он получил -EPERM.

Вы можете проверить euid, uid, pid и comm в своем коде. Как это:

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);
person shuofei    schedule 10.06.2015
comment
Есть ли способ изменить такое поведение (чтобы обработчик работал с той же привилегией, что и запускающий процесс), снова взломав IDT? - person Richard; 11.06.2015
comment
@ Ричард К сожалению, нет. - person shuofei; 11.06.2015