Как лучше понять и реверс-инжиниринг системных вызовов внутри процессов на конкретном примере

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

Как следует из названия, я представляю пример, являющийся моим анализом процесса Xorg, который я отслеживал в моем окружении рабочего стола Linux. Таким образом, я пытаюсь понять процесс выполнения вызовов DRM_IOCTL, в данном случае специфического системного вызова DRM_IOCTL_CURSOR2, который происходит в этом процессе. Моя цель – понять, что вызывает этот вызов в этом окружении рабочего стола, или скорее, какие шаги я могу предпринять в общем, чтобы исследовать подобные вопросы.

Из моего ограниченного понимания я знаю, что Xorg запускается как подпроцесс SDDM, но помимо инициации сервера Xorg, у меня нет представления о том, как пройти через процесс и определить триггеры для некоторых процессных вызовов или, возможно, использовать инструменты для этого. Таким образом, это концептуальный вопрос о том, как подойти к анализу таких вопросов в общем. Потребуются ли здесь какие-то специфические знания о текущем процессе и его архитектуре. Могу ли я воспользоваться какими-либо общими подходами на моей системе для отслеживания системных вызовов, подобно выявлению ppids процессов для моего собственного интереса.

На данный момент я слабо знаком с использованием таких инструментов, как strace, bpftrace и общие командные инструменты, такие как ps и lsof. Извиняюсь, если это общий вопрос, если так, я буду рад сузить его еще больше.

Да, это звучит хорошо: bpftrace, чтобы определить, как часто делается системный вызов и кем, а также strace, чтобы выяснить, какие системные вызовы делает конкретный процесс. Значительная часть достигнута!

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

По умолчанию отладчик в Linux – это gdb. Давайте проведем вас через это.

Предварительное условие (пока): Наличие отладочных символов для вашего процесса. Это легко, если вы что-то создали сами и включены отладочные символы (но тогда, что же вы декомпилируете); это легко, если вы можете использовать возможности вашей системы для загрузки для вас отладочной информации. Мне нравится, что Fedora (и другие основные дистрибутивы Linux, такие как Debian или Ubuntu) предлагают символы debuginfod, это делает данный процесс значительно проще.

0. Установите gdb.
1. Установите переменную среды, указывающую gdb, где найти данные debuginfod (необязательно, но делает вещи намного читабельнее для начала; отрегулируйте URL для вашего дистрибутива):

   export DEBUGINFOD_URLS=https://ubuntu.com/server/docs/about-debuginfod
   

2. найдите ID процесса (pid) процесса, с которым вы хотите работать (например, с помощью bpftrace)
3. подключите gdb к этому PID: gdb --pid the_pid_you_care_about. На этом этапе, возможно, потребуется загрузить много отладочной информации.
4. скажите gdb поймать все системные вызовы, которые являются ioctl, а затем продолжите выполнение:

   (gdb) catch syscall ioctl
   (gdb) continue
   

5. вас вернут к интерфейсу gdb каждый раз, когда вызывается ioctl; в этот момент вы можете сделать, например, backtrace, чтобы увидеть стек вызовов, включая имена функций, и print переменные из текущего кадра стека (если они не были оптимизированы компилятором)
6. вы можете detach от процесса или quit (и убить его)

В любом случае, то, как работает пункт 5, немного неудобно: вы на самом деле не хотите останавливаться на каждом ioctl, только на ioctl с конкретными аргументами, и вы не очень хотите останавливаться, вы хотите сделать обратный трассировку и записать это в файл, возможно. Так что, вместо 4-го пункта вы могли бы сделать:

(gdb) set logging on
(gdb) set logging file ~/mylog.txt
(gdb) catch syscall ioctl
(gdb) commands
backtrace
continue
end
(gdb) continue

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

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