Переопределяющая функциональность с модулями в ядре Linux

взгляните на http://www.tldp.org/LDP/lkmpg/2.6/html/x978.html

Вы не хотите изменять существующие системные вызовы, Вы хотите оснастить их. Это - то, для чего SystemTap. Если Вы действительно хотите сделать это твердый путь и прервать системные вызовы путем кодирования собственного модуля, я предполагаю, что Вы читаете некоторую литературу руткита, но у меня нет ссылки удобной (хотя phrack приходит на ум).

Большая часть работы файловой системы уже сделана в модулях, предположив, что код файловой системы был создан как модуль, а не встроен в ядро (что означает, что 'реальный' ответ зависит от опций сборки ядра).

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

, Если те предположения не верны, или не могут быть сделаны верными, то вещи ясно становятся более хитрыми, и я действительно не мог указать на Вас гораздо дальше.

Так как Вы хотите только зарегистрировать вызовы (т.е. Вы на самом деле не переопределите их), и небольшое количество изменений в коде ядра приемлемо, самый чистый путь состоял бы в том, чтобы добавить рычаг к каждой функции, Вы интересуетесь (использование notifier цепочки или даже простого указателя функции). Ваш модуль затем просто регистрирует себя ко всем рычагам, которые Вы добавили (и нерегистры от них при разгрузке).

также довольно возможно, что кто-то еще уже сделал работу добавления рычагов для Вас.

Я думаю, что можно использовать аудит для этого

Я не совсем уверен, что понимаю то, что Вы хотите сделать, но я думаю, что ksplice может быть хорошим решением. Это все еще разрабатывается, таким образом, я не знаю, находится ли это в каком-либо виде применимого условия прямо сейчас.

Была большая работа, сделанная в ядре, чтобы удостовериться, что это не происходит, особенно работает для не представления syscall таблицы модулям. Единственный поддерживаемый механизм к доступу файла журнала LSM, но он ориентирован к безопасности и имеет неопределенное будущее . Здесь PDF, который документирует API, но это не может быть актуально.

inotify является намного лучшим способом контролировать создание, удаление и модификацию файлов, чем попытка ниспровергать ядро syscall функции, но это работает от пространства пользователя.

Заключенный в кавычки из Википедии ( http://en.wikipedia.org/wiki/Inotify ): Некоторые события, которые могут следиться за развитием для:

* IN_ACCESS - read of the file
* IN_MODIFY - last modification
* IN_ATTRIB - attributes of file change
* IN_OPEN and IN_CLOSE - open or close of file
* IN_MOVED_FROM and IN_MOVED_TO - when the file is moved or renamed
* IN_DELETE - a file/directory deleted
* IN_CREATE - a file/directory created
* IN_DELETE_SELF - file monitored is deleted

inotify существует в ядре, так как 2.6.13, его предшественник является dnotify ( http://en.wikipedia.org/wiki/Dnotify ).

Вы, вероятно, хотите к , сцепляют системные вызовы (ссылка PDF), который эффективно позволил бы Вам зарегистрировать пользовательские процессы, вызывающие функции ядра. Если Вы действительно хотите зарегистрироваться ядро использование функций ядра, Вы хотите изучить трассировка функции ядра .

Вы смотрели на развертывание своей функции с помощью LD_PRELOAD?

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

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

Возможно, посмотрите статью « Создание интерпретаторов библиотек для развлечения и прибыли ». Хотя это специфично для Solaris, оно также применимо к Linux.

Кстати, именно так работают большинство инструментов анализа памяти, например Purify.

Согласно KernelTrap.org , вы можете сделать простой патч и перекомпилировать свое ядро, чтобы экспортировать переменную sys_call_table:

// add the following in the file arch/i386/kernel/i386_ksyms.c
extern void* sys_call_table[];
EXPORT_SYMBOL(sys_call_table);

Затем просто выполните эту процедуру для замена системных вызовов из Руководства по программированию модуля ядра Linux:

Исходный код здесь является примером такой модуль ядра. Мы хотим шпионить для определенного пользователя и printk () a сообщение всякий раз, когда этот пользователь открывает файл. С этой целью заменим системный вызов для открытия файла с нашим собственная функция, называемая our_sys_open . Эта функция проверяет uid (пользователя id) текущего процесса, а если это равно UID, за которым мы шпионим, это вызывает printk () для отображения имени файл, который нужно открыть. Тогда либо way, it calls the original open() function with the same parameters, to actually open the file.

The init_module function replaces the appropriate location in sys_call_table and keeps the original pointer in a variable. The cleanup_module function uses that variable to restore everything back to normal. This approach is dangerous, because of the possibility of two kernel modules changing the same system call. Imagine we have two kernel modules, A and B. A's open system call will be A_open and B's will be B_open. Now, when A is inserted into the kernel, the system call is replaced with A_open, which will call the original sys_open when it's done. Next, B is inserted into the kernel, which replaces the system call with B_open, which will call what it thinks is the original system call, A_open, when it's done.

Это может оказаться полезным для вас.

В основном, поскольку таблица системных вызовов не экспортируется напрямую в новых ядрах, вам нужно выполнить поиск, чтобы определить ее местоположение сами. Затем вы можете перехватывать выбранные вами системные вызовы и манипулировать ими. Однако заменить другие функции ядра будет намного сложнее, если только некоторые из них не будут организованы так же, как системные вызовы (они появляются в некоторых таблицах диспетчеризации и т. Д.), Что не является обычным явлением.