Перехват системных вызовов в 2.6

> Я так понимаю что можно таблицу просто найти зная адрес одного из системных вызовов, но это на мой взгляд не очень правильно.

а другого варианта фактически нет :)

сканируем память ядра на предмет таблицы символов, в ней ищем заведомо экспортируемые [есть там парочка] и дальше по их адресам сканируем память в поисках таблицы системных вызовов. при аккуратной реализации вполне работает.

// wbr

я делал это по другому: пишется юзерспейсная прога, которая работает как отладчик, и шагает по ptrace(PTRACE_SYSCALL, ...). распарсить номер сусколла и аргументы - дело техники.

И как это поможет изменять логику сискола на нагруженном сервере?

>> Как этом можно сделать максимально красиво?

Перехват системных вызовов - это не красиво по определению. Скажи для чего именно тебе это нужно, возможно есть более правильный путь.

>> Я так понимаю что можно таблицу просто найти зная адрес одного из системных вызовов, но это на мой взгляд не очень правильно.

Правильного способа нет, в любом случае получается хак. Но вообще способов много.

1) Можно заменить начало кода целевой функции на переход на свою функцию. Но это очень архитектурно-зависимо и нужно писать вставки на ассемблере. [очень злой хак - можно завалить систему]

2) Зная адреса системных вызовов с последовательными номерами (т.е. 1, 2, 3, 4, ...), можно поискать в памяти эту последовательность. [менее злой хак, но возможно не всегда работает]

3) Самый простой способ:

grep -Fw sys_call_table /lib/modules/$(uname -r)/build/System.map | cut -d ' ' -f 1

И полученное значение передать при сборке через например через -DSYS_CALL_TABLE_DEF=0x12345678. В коде сделать так:

static void **sys_call_table = SYS_CALL_TABLE_DEF;

4) Можно нагуглить что-нибудь ещё.

Вообщем нужно после смены uid процесса (например setuid, exec), менять его группу планировщика (sched_group_*).

так это делается, вроде, schedutils. Почитай Documentation/sched.txt или как там эта байда называется