Feb 8, 2025

4. Глава. Написание первого модуля ядра - часть 1

В предыдущих двух главах вы узнали все тонкости получения дерева исходного кода ядра и настройки и сборки его (для x86). Теперь добро пожаловать в ваше путешествие по изучению фундаментального аспекта разработки ядра Linux – фреймворка Загружаемых Модулей Ядра (LKM) – и как он используется пользователем или автором модуля, который обычно является программистом ядра или драйверов устройств. Эта тема довольно обширна, поэтому она разделена на две главы – эту и следующую. В этой главе мы начнем с быстрого обзора основ архитектуры ядра Linux, что поможет нам понять фреймворк LKM. Затем мы рассмотрим, почему модули ядра полезны, напишем, соберем и запустим наш простой модуль “Hello, world” LKM. Мы увидим, как сообщения записываются в журнал ядра, и поймем и используем Makefile для LKM. К концу этой главы вы узнаете основы архитектуры ядра Linux и фреймворка LKM, применив это знание для написания простого, но полного куска кода ядра. В этой главе мы рассмотрим следующие рецепты:

• Понимание архитектуры ядра – часть 1
• Изучение LKM
• Написание нашего первого модуля ядра
• Общие операции с модулями ядра
• Понимание логирования ядра и printk
• Понимание основ Makefile модуля ядра

Технические требования

Если вы уже внимательно следовали инструкциям из онлайн главы “Kernel Workspace Setup”, то часть технических предпосылок, которые следуют, уже будет выполнена. (Первая глава также упоминает различные полезные открытые инструменты и проекты; я определенно рекомендую просмотреть её хотя бы один раз.) Для вашего удобства мы суммируем здесь некоторые ключевые моменты.

Для сборки и использования внешнего (или вне-дерева) модуля ядра на дистрибутиве Linux (или кастомной системе), вам нужно:

• Ядро должно быть собрано с поддержкой модулей (CONFIG_MODULES=y)
• Как минимум, должны быть установлены следующие два компонента:
  • Инструментарий: включает компилятор, ассемблер, линкер/загрузчик, библиотеку C и различные другие части. Если сборка для локальной системы, как мы предполагаем сейчас, то любой современный дистрибутив Linux будет иметь предустановленный нативный инструментарий. Если нет, то установка пакета GCC для вашего дистрибутива должна быть достаточной; на системе на базе Ubuntu или Debian используйте это:

      sudo apt install gcc
    

  • Заголовочные файлы ядра: эти заголовки будут использоваться во время компиляции LKM. На практике, вы устанавливаете пакет, предназначенный не только для установки заголовочных файлов ядра, но также других необходимых частей (таких как Makefile ядра) на систему. Опять же, любой современный дистрибутив Linux должен иметь предустановленные заголовки ядра. Если нет (вы можете проверить с помощью утилиты dpkg, как показано здесь), просто установите пакет для вашего дистрибутива; на системе на базе Ubuntu или Debian используйте это:

      $ sudo apt install linux-headers-generic
      $ dpkg -l | grep linux-headers | awk '{print $1, $2}'
      ii linux-headers-5.19.0-45-generic
      ii linux-headers-generic-hwe-22.04
    

    Здесь вторая команда с использованием утилиты dpkg используется просто для проверки установки пакетов linux-headers.

Этот пакет может называться kernel-headers-<ver#> на некоторых дистрибутивах. Также, для разработки непосредственно на Raspberry Pi, установите соответствующий пакет заголовочных файлов ядра, названный raspberrypi-kernel-headers.

На всякий случай, если вы не можете собирать модули, попробуйте это: подготовьте ядро для сборки внешних модулей, выполнив make modules_prepare в корне вашего дерева исходного кода ядра. С типичными современными дистрибутивами, вам не должно понадобиться это делать; сборка модулей должна просто работать.

Весь исходный код для этой книги доступен в её репозитории на GitHub по адресу: https://github.com/PacktPublishing/Linux-Kernel-Programming_2E; мы ожидаем, что вы клонируете его:

git clone \
  https://github.com/PacktPublishing/Linux-Kernel-Programming_2E.git

Код для этой главы находится в соответствующей директории, обозначенной как chn (где n - номер главы; таким образом, здесь это будет ch4/).

Понимание архитектуры ядра – часть 1

В этом разделе мы начинаем углублять наше понимание ядра Linux. Конкретно, здесь мы рассмотрим, что такое пространства пользователя и ядра, а также основные подсистемы и различные компоненты, из которых состоит ядро. Эта информация рассматривается на более высоком уровне абстракции и намеренно держится кратко. Мы значительно углубим понимание структуры ядра в главе 6, “Kernel Internals Essentials – Processes and Threads”.

Пространство пользователя и пространство ядра

Современные микропроцессоры поддерживают выполнение кода как минимум на двух уровнях привилегий. В качестве примера из реальной жизни, семейство процессоров Intel/AMD x86[-64] поддерживает четыре уровня привилегий (их называют уровнями кольца), семейство микропроцессоров AArch32 (ARM-32) поддерживает до семи режимов (ARM называет их режимами выполнения; шесть из них привилегированы и один не привилегирован), а семейство микропроцессоров AArch64 (ARM-64/ARMv8) поддерживает четыре уровня исключений (EL0 до EL3, где EL0 наименее привилегирован, а EL3 наиболее привилегирован).

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

• Пространство пользователя: Для выполнения приложений в непривилегированном пользовательском режиме. Все приложения – процессы и потоки – будут выполняться на этом уровне привилегий в этом пространстве. Сейчас, возможно, вы используете браузер, редактор, читалку PDF, терминал, почтовый клиент и т.д. Все это приложения – в конечном итоге, процессы и потоки; на Linux они все выполняются в пространстве пользователя в пользовательском режиме, который является непривилегированным. Скоро мы придем к пониманию того, что именно подразумевается под терминами “привилегированный” и “непривилегированный”.
• Пространство ядра: Для выполнения ядра (и всех его компонентов) в привилегированном режиме – режиме ядра. Это домен операционной системы и всего, что в ней (например, драйвера, сетевые функции, ввод-вывод и т.д., включая модули ядра). Все это работает с привилегиями ОС; по сути, они могут делать все, что угодно! Обратите внимание, что этот уровень привилегий является аппаратной особенностью и не то же самое, что выполнение как root или нет (это чисто программный артефакт); в многих случаях выполнение с привилегиями ядра можно рассматривать как эффективное выполнение как root.

Следующая фигура демонстрирует эту базовую архитектуру:

![[figure41.png]] Рисунок 4.1: Базовая архитектура – два адресных пространства, два режима привилегий

Далее следует несколько деталей о системной архитектуре Linux; продолжайте чтение.

Библиотеки и API системных вызовов

Приложения в пространстве пользователя часто используют интерфейсы программирования приложений (API) для выполнения своей работы. Библиотека по сути является коллекцией или архивом API, что позволяет использовать стандартизированный, хорошо написанный и протестированный интерфейс (и получать обычные преимущества: не изобретать велосипед с нуля, обеспечивать переносимость, стандартизацию и т.д.). В системах Linux есть множество библиотек; на системах корпоративного уровня их могут быть даже сотни. Из них все приложения Linux в режиме пользователя (исполняемые файлы) “автоматически связываются” с одной важной, постоянно используемой библиотекой: glibc – это стандартная библиотека GNU C, как вы узнаете. Однако библиотеки всегда доступны только в пользовательском режиме; ядро не использует эти библиотеки пользовательского режима (подробнее об этом в следующей главе).

Примеры API библиотек включают такие известные как printf(3), scanf(3), strcmp(3), malloc(3) и free(3). (Напомним, из онлайн главы “Kernel Workspace Setup”, раздел “Using the Linux man pages”.)

Теперь ключевой момент: если пользовательское и ядерное пространства являются отдельными адресными пространствами и находятся на разных уровнях привилегий, как процесс пользователя – который, как мы только что узнали, ограничен пространством пользователя – может получить доступ к ядру? Краткий ответ: через системные вызовы. Системный вызов – это особый API в том смысле, что он является единственным легальным (синхронным) способом для процессов (или потоков) пространства пользователя получить доступ к ядру. Другими словами, системные вызовы являются единственной легальной точкой входа в пространство ядра.

Системные вызовы имеют встроенную способность переключаться из непривилегированного пользовательского режима в привилегированный режим ядра (подробнее об этом и монолитной архитектуре в главе 6, “Kernel Internals Essentials – Processes and Threads”, в разделе “Process and interrupt contexts”). Примеры системных вызовов включают fork(2), execve(2), open(2), read(2), write(2), socket(2), accept(2), chmod(2) и так далее.

Посмотрите все API библиотек и системные вызовы в онлайн-мануалах:

• API библиотек, раздел man 3: https://linux.die.net/man/3/
• API системных вызовов, раздел man 2: https://linux.die.net/man/2/

Основным акцентом здесь является то, что только через системные вызовы пользовательские приложения (процессы и потоки) и ядро взаимодействуют – это и есть интерфейс. В этой книге мы не углубляемся в эти детали. Если вас интересует больше информации, пожалуйста, обратитесь к моей предыдущей книге “Hands-On System Programming with Linux”, Packt (конкретно к главе 1, “Linux System Architecture”).

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

Компоненты пространства ядра

Конечно, эта книга полностью сфокусирована на пространстве ядра. Сегодня ядро Linux – это довольно большой и сложный механизм. Внутри него есть несколько основных подсистем и множество компонентов. Широкий перечень подсистем и компонентов ядра включает следующее:

• Ядро: Этот код занимается обычной тяжелой работой любой современной операционной системы, включая создание/уничтожение процессов и потоков пользователя и ядра, планирование работы процессора, примитивы синхронизации, сигналы, таймеры, обработку прерываний, пространства имен, группы контроля cgroups, поддержку модулей, криптографию и многое другое.
• Управление памятью (MM): Обрабатывает всю работу, связанную с памятью, включая настройку и поддержку виртуальных адресных пространств (VAS) ядра и процессов.

• VFS (для поддержки файловых систем): Виртуальный коммутатор файловых систем (VFS) является абстракционным слоем над реальными файловыми системами, реализованными в ядре Linux (например, ext[2

  4], vfat, ntfs, msdos, iso9660, f2fs, ufs и многими другими).

• Блочный ввод/вывод: Пути кода, реализующие фактический ввод/вывод файлов, от файловых систем вплоть до драйверов блочных устройств и всего, что между ними (на самом деле, это довольно много!), включены здесь.
• Стек сетевых протоколов: Linux известен своей точной, соответствующей RFC, высококачественной реализацией известных (и менее известных) сетевых протоколов на всех уровнях модели, причем TCP/IP, возможно, самый известный из них.
• Поддержка межпроцессного взаимодействия (IPC): Реализация механизмов IPC делается здесь; Linux поддерживает очереди сообщений, разделяемую память, семафоры (как старые SysV, так и новые POSIX), и другие механизмы IPC.
• Поддержка звука: Весь код, реализующий аудио, здесь, от прошивки до драйверов и кодеков.
• Поддержка виртуализации: Linux стал чрезвычайно популярным как среди крупных, так и среди небольших провайдеров облачных услуг, одной из главных причин этого является его высококачественный, легковесный виртуализационный движок, основанный на ядре, Kernel-based Virtual Machine (KVM).

Все это составляет основные подсистемы ядра; кроме того, у нас есть:

• Код, специфичный для архитектуры (то есть специфичный для процессора)
• Инициализация ядра
• Фреймворки безопасности
• Многие типы драйверов устройств

Вспомните, что в главе 2, “Сборка ядра Linux 6.x из исходного кода – Часть 1”, в разделе “Краткий обзор дерева исходного кода ядра” был дан обзор структуры дерева исходного кода ядра, соответствующий основным подсистемам и другим компонентам.

Хорошо известно, что ядро Linux следует монолитной архитектуре ядра (в противоположность микроядерной архитектуре). В монолитном дизайне все компоненты ядра (которые мы упомянули в этом разделе) существуют и разделяют виртуальное адресное пространство ядра (VAS) или сегмент ядра. Это можно четко увидеть на следующей диаграмме:

![[figure42.png]] Рисунок 4.2: Пространство ядра Linux – основные подсистемы и блоки

Еще один факт, о котором следует знать, заключается в том, что эти адресные пространства, конечно же, являются виртуальными адресными пространствами, а не физическими. Ядро будет сопоставлять, на уровне гранулярности страниц, виртуальные страницы с физическими фреймами страниц, используя аппаратные блоки, такие как блок управления памятью (MMU) и кэш процессора, плюс кэш трансляционных буферов (TLB), для повышения эффективности. Это делается с помощью главной таблицы страничной памяти ядра для сопоставления виртуальных страниц ядра с физическими фреймами (ОЗУ), и для каждого живого процесса пространства пользователя оно сопоставляет виртуальные страницы процесса с физическими фреймами страниц через индивидуальные таблицы страничной памяти для каждого процесса.

Более углубленное освещение основ архитектуры и внутренностей ядра и управления памятью ожидает вас в главе 6, “Kernel Internals Essentials – Processes and Threads” (и последующих главах).

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

Исследование LKM

Модуль ядра - это способ предоставления функциональности на уровне ядра без необходимости работы непосредственно в дереве исходного кода ядра и с использованием статического образа ядра.

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

Хотя это может показаться простым, это много работы – каждое изменение в написанном нами коде, независимо от того, насколько оно мало, потребует перестроения образа ядра и перезагрузки системы для его тестирования. Должен быть более чистый и простой способ; действительно, существует – фреймворк LKM!

Фреймворк LKM

Фреймворк LKM позволяет компилировать часть кода ядра обычно вне дерева исходного кода ядра, часто называемого “вне-деревом” кодом, сохраняя его в ограниченной степени независимым от ядра, а затем вставлять или подключать созданный “объект модуля” в память ядра, в виртуальное адресное пространство ядра, запускать его и выполнять его работу, а затем удалять его (или отключать) из памяти ядра. (Обратите внимание, что фреймворк LKM также может использоваться для создания модулей ядра внутри дерева, как мы делали при сборке ядра. Здесь мы сосредоточимся на модулях вне дерева).

Исходный код модуля ядра, обычно состоящий из одного или нескольких файлов на C, заголовочных файлов и Makefile, компилируется (с помощью make, конечно) в модуль ядра. Сам модуль ядра является лишь бинарным объектным файлом, а не исполняемым бинарным файлом. В Linux 2.4 и ранее, имя файла модуля ядра имело суффикс .o; в современных версиях Linux 2.6 и позже, он имеет суффикс .ko (объект ядра). После сборки, вы можете вставить этот файл .ko – модуль ядра – в работающее ядро во время выполнения, тем самым сделав его частью ядра.

Обратите внимание, что не вся функциональность ядра может быть предоставлена через фреймворк LKM. Несколько основных функций, таких как базовый код планировщика задач (CPU), управление памятью, сигнализация, таймеры, пути кода управления прерываниями, специфичные для платформы драйвера для управления контроллерами пинов, часами и т.д., могут быть разработаны только внутри самого ядра. Аналогично, модулю ядра разрешён доступ только к подмножеству полного API ядра и переменных данных; об этом мы поговорим позже.

Вы можете спросить: как вставить этот объект модуля в ядро во время выполнения? Давайте упростим - ответ заключается в использовании утилиты insmod. Пока что мы пропустим детали (они будут объяснены в предстоящем разделе “Running the kernel module”). Следующая фигура дает обзор процесса первоначальной сборки и последующей вставки модуля ядра в память ядра:

![[figure43.png]] Рисунок 4.3: Сборка и последующая вставка модуля ядра в память ядра

Не беспокойтесь: фактический код как для C-исходников модуля ядра, так и для его Makefile будет рассмотрен глубоко в предстоящем разделе; пока что мы хотим получить только концептуальное понимание.

Модуль ядра загружается и существует в памяти ядра – то есть, в виртуальном адресном пространстве ядра (VAS) (нижняя часть рисунка 4.3) в области пространства, выделенной для него ядром. Не заблуждайтесь, это код ядра и он выполняется с привилегиями ядра.

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

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

Еще одним преимуществом ядровых модулей является их способность к динамической конфигурации продукта. Например, модули ядра могут быть разработаны для предоставления различных функций по разным ценам; скрипт, создающий финальный образ для встраиваемого продукта, может установить определённый набор модулей ядра в зависимости от цены, которую готов заплатить клиент. Вот еще один пример использования этой технологии в сценарии отладки или устранения неполадок: модуль ядра может быть использован для динамического создания диагностических данных и отладочных журналов на существующем продукте. Технологии вроде Kprobes и подобные позволяют это сделать (мои книги по отладке ядра Linux охватывают это в деталях). Фактически, фреймворк LKM предоставляет нам способ динамически расширять функциональность ядра, позволяя нам вставлять (и позже удалять) живой код в (из) памяти ядра. Эта возможность подключать и отключать функциональность ядра по нашему желанию заставляет нас осознать, что ядро Linux не является чисто монолитным, оно также модульное.

Модули ядра внутри дерева исходного кода ядра

На самом деле, объект модуля ядра нам не совсем незнаком. В главе 3, “Building the 6.x Linux Kernel from Source – Part 2”, мы собирали модули ядра как часть процесса сборки ядра и устанавливали их.

Вспомните, что эти модули ядра являются частью исходного кода ядра и были настроены как модули путем выбора M в приглашении конфигурационного меню ядра. Они устанавливаются в директории под /lib/modules/$(uname -r)/. Таким образом, чтобы немного узнать о модулях ядра, установленных под нашим текущим ядром гостевой системы Ubuntu 22.04 LTS на x86_64, мы можем сделать следующее:

$ lsb_release -a 2>/dev/null |grep Description
Description: Ubuntu 22.04.2 LTS
$ uname -r
5.19.0-45-generic
$ find /lib/modules/$(uname -r)/ -name "*.ko" | wc -l
6189

Хорошо поработали ребята из Canonical и других мест! Более шести тысяч модулей ядра… Подумайте об этом, это логично: дистрибьюторы не могут заранее знать, какое именно аппаратное обеспечение будет использовать пользователь (особенно на универсальных компьютерах, таких как x86 PC). Модули ядра служат удобным средством поддержки огромного количества оборудования без чрезмерного раздувания файла изображения ядра (например, файлы bzImage или Image).

Установленные модули ядра для нашей системы Ubuntu Linux располагаются в директории /lib/modules/$(uname -r)/kernel, как показано здесь:

$ ls /lib/modules/5.19.0-45-generic/kernel/
arch/ block/ crypto/ drivers/ fs/ kernel/ lib/ mm/ net/ 
samples/ sound/ ubuntu/ v4l2loopback/ zfs/
$ ls /lib/modules/6.1.25-lkp-kernel/kernel/
arch/ crypto/ drivers/ fs/ lib/ net/ sound/

Здесь, рассматривая верхний уровень директории kernel/ под /lib/modules/$(uname -r) для ядра дистрибутива (Ubuntu 22.04 LTS с запущенным ядром 5.19.0-45-generic), мы видим, что здесь множество подпапок и буквально несколько тысяч модулей ядра. Напротив, для ядра, которое мы собрали (см. главу 2, “Building the 6.x Linux Kernel from Source – Part 1”, и главу 3, “Building the 6.x Linux Kernel from Source – Part 2”, для деталей), их значительно меньше. Вы, вероятно, помните из наших обсуждений в главе 2, что мы специально использовали целевую настройку localmodconfig для того, чтобы сборка оставалась (относительно) маленькой и быстрой. Таким образом, например, наше собственное ядро версии 6.1.25 имеет всего около 70 модулей ядра, собранных для него.

Одна из областей, где модули ядра используются наиболее активно, - это драйверы устройств. Например, давайте посмотрим на драйвер сетевого устройства, который архитектурно построен как модуль ядра. Вы можете найти несколько (с знакомыми названиями брендов!) в папке kernel/drivers/net/ethernet дистрибутива:

![[figure44.png]] Рисунок 4.4: Содержимое папки драйверов сети Ethernet (модулей ядра) нашего дистрибутива

Популярным в многих ноутбуках на базе Intel является сетевой адаптер Intel 1GbE Network Interface Card (NIC). Драйвер сетевого устройства, который его обслуживает, называется драйвером e1000 (более новые системы, возможно, используют более позднюю модель, и, следовательно, модуль драйвера e1000e).

Удобный способ просмотреть все модули ядра, которые сейчас находятся в памяти ядра, - это использование утилиты lsmod (читайте как “list mod(ules)” – мы позже узнаем больше о формате её вывода). Наш гость Ubuntu 22.04 на x86_64 (запущенный на ноутбуке хоста x86_64) показывает, что он действительно использует этот драйвер:

$ lsmod | grep e1000
e1000 159744 0

Важно для нас сейчас то, что драйвер e1000 является модулем ядра! Как насчет получения дополнительной информации об этом конкретном модуле ядра? Это легко сделать, используя утилиту modinfo (для удобства чтения здесь мы сократили её подробный вывод):

$ ls -l /lib/modules/5.19.0-45-generic/kernel/drivers/net/ethernet/intel/e1000
total 364
-rw-r--r-- 1 root root 372185 7 июн 19:53 e1000.ko
$ modinfo /lib/modules/5.19.0-45-generic/kernel/drivers/net/ethernet/intel/
e1000/e1000.ko
filename: /lib/modules/5.19.0-45-generic/kernel/drivers/net/ethernet/
intel/e1000/e1000.ko
license: GPL v2
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>
srcversion: F35F102C5522A6614A9D65C
alias: pci:v00008086d00002E6Esv*sd*bc*sc*i*
alias: pci:v00008086d000010B5sv*sd*bc*sc*i*
[ ... ]
intree: Y
name: e1000
vermagic: 5.19.0-45-generic SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: Build time autogenerated kernel key
[ ... ]
parm: SmartPowerDownEnable:Enable PHY smart power down (массив int)
parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm: debug:Debug level (0=none,...,16=all) (int)
$

Утилита modinfo позволяет нам заглянуть в бинарный образ модуля ядра и извлечь некоторые детали о нем; больше о использовании modinfo будет рассказано в следующем разделе.

Вы можете обнаружить, что файл модуля ядра сжат (например, e1000.ko.xz); это особенность, а не ошибка (больше об этом позже). Еще один способ получить полезную информацию о системе, включая информацию о загруженных модулях ядра, - это использование утилиты systool. Для установленного модуля ядра (детали по установке модуля ядра будут приведены в следующей главе, в разделе “Автозагрузка модулей при запуске системы”), выполнение systool -m <имя_модуля> -v раскрывает информацию о нем. Посмотрите страницу руководства systool(1) для деталей использования.

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

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

Написание нашего самого первого модуля ядра

При введении нового языка программирования или темы стало широко принятой традицией в программировании воспроизвести оригинальную программу “Hello, world” в качестве первого куска кода. Я рад следовать этой почитаемой традиции, чтобы ввести мощный фреймворк LKM ядра Linux. В этом разделе вы узнаете шаги для написания простого LKM. Мы подробно объясним код.

Введение нашего кода на C для LKM “Hello, world”

Без лишних слов, вот простой код на C “Hello, world”, реализованный в соответствии с фреймворком LKM ядра Linux:

По причинам читаемости и ограничения пространства здесь показаны только ключевые части большинства исходного кода. Чтобы просмотреть полный исходный код (со всеми комментариями), собрать его и запустить, весь исходный код для этой книги доступен в его репозитории на GitHub здесь: https://github.com/PacktPublishing/Linux-Kernel-Programming_2E. Мы определенно ожидаем, что вы клонируете его и будете использовать:

git clone https://github.com/PacktPublishing/Linux-Kernel-Programming_2E.git

$ cat <LKP2E_src>/ch4/helloworld_lkm/helloworld_lkm.c
// ch4/helloworld_lkm/helloworld_lkm.c
#include <linux/init.h>
#include <linux/module.h>

/* Модульные вещи */
MODULE_AUTHOR("<insert your name here>");
MODULE_DESCRIPTION("LKP2E book:ch4/helloworld_lkm: hello, world, our first LKM");
MODULE_LICENSE("Dual MIT/GPL");
MODULE_VERSION("0.2");

static int __init helloworld_lkm_init(void)
{
    printk(KERN_INFO "Hello, world\n");
    return 0; /* успех */
}

static void __exit helloworld_lkm_exit(void)

{
    printk(KERN_INFO "Goodbye, world! Climate change has done us in...\n");
}
module_init(helloworld_lkm_init);
module_exit(helloworld_lkm_exit);

Вы можете сразу же попробовать этот простой модуль ядра “Hello, world”! Просто перейдите в правильный исходный каталог и используйте наш вспомогательный скрипт lkm, чтобы собрать и запустить его:

$ cd ~/Linux-Kernel-Programming_2E/ch4/helloworld_lkm
$ ../../lkm helloworld_lkm.c
Usage: lkm name-of-kernel-module-file ONLY (do NOT put any extension).
$ ../../lkm helloworld_lkm
Version info:
Distro: Ubuntu 22.04.2 LTS
Kernel: 5.19.0-45-generic
[ … ]
make || exit 1
------------------------------
make -C /lib/modules/5.19.0-45-generic/build/ M=/home/c2kp/Linux-KernelProgramming_2E/ch4/helloworld_lkm modules
[ … ]
sudo dmesg
------------------------------
[ 4123.028252] Hello, world
$

Как и почему это работает, будет объяснено очень подробно в ближайшее время. Хотя код этого, нашего первого модуля ядра, очень маленький, он требует тщательного изучения и понимания. Продолжайте читать!

Распределение по пунктам

В следующих подразделах объясняется практически каждая строка предыдущего кода на C для LKM “Hello, world”. Помните, что хотя программа кажется очень маленькой и простой, есть многое, что нужно понять о ней и окружающем фреймворке LKM. Остальная часть этой главы сосредоточена на этом и входит в детали. Я настоятельно рекомендую потратить время на чтение и понимание этих основ. Это очень поможет вам в дальнейшем, возможно, в ситуациях, которые сложно отлаживать.

Заголовочные файлы ядра

Первое, что мы делаем в коде - это используем #include для (очевидного) включения нескольких заголовочных файлов. В отличие от разработки приложений на C в пространстве пользователя, здесь используются заголовочные файлы ядра (как упоминалось в разделе “Технические требования”). Вспомните из главы 3, “Building the 6.x Linux Kernel from Source – Part 2”, что модули ядра были установлены под определенной веткой, доступной для записи только пользователем root.

Давайте проверим это снова (здесь мы работаем на нашей гостевой виртуальной машине Ubuntu x86_64 с ядром дистрибутива 5.19.0-45-generic):

$ ls -l /lib/modules/$(uname -r)
total 6712
lrwxrwxrwx 1 root root 40 7 июн 19:53 build -> /usr/src/linux-headers-5.19.0-45-generic
drwxr-xr-x 2 root root 4096 23 июн 09:47 initrd
[ ... ]

Обратите внимание на символическую или мягкую ссылку здесь под названием build. Она указывает на местоположение заголовочных файлов ядра в системе. В предыдущем блоке кода вы можете увидеть, что это в директории /usr/src/linux-headers-5.19.0-45-generic/! Как вы увидите, мы предоставим эту информацию для Makefile, используемого для сборки нашего модуля ядра. (Также, на некоторых системах есть аналогичная мягкая ссылка, называемая source.)

Пакет kernel-headers или linux-headers распаковывает ограниченное дерево исходного кода ядра на системе, обычно под /usr/src/…. Однако эта база кода ядра не является полной, поэтому мы используем выражение “ограниченное дерево исходного кода”. Это потому, что для сборки модулей не требуется полное дерево исходного кода ядра – достаточно только необходимых компонентов (заголовки, Makefile и т.д.), которые упакованы и извлечены.

Первая строка кода в нашем модуле ядра “Hello, world” - это #include <linux/init.h>. Компилятор разрешает эту строку, выполняя поиск вышеупомянутого файла заголовка ядра в директории /lib/modules/$(uname -r)/build/include/. Таким образом, следуя за мягкой ссылкой build, мы видим, что в итоге он выбирает этот файл заголовка:

$ ls -l /usr/src/linux-headers-5.19.0-45-generic/include/linux/init.h
-rw-r--r-- 1 root root 11963 1 авг 2022 /usr/src/linux-headers-5.19.0-45-generic/include/linux/init.h

То же самое относится и к другим заголовочным файлам ядра, включенным в исходный код модуля ядра.

Макросы модуля

Далее у нас есть несколько макросов модуля вида MODULE_FOO(); (неформально называемых “модульные вещи”). Большинство из них довольно интуитивны:

• MODULE_AUTHOR(): Указывает автора(ов) модуля ядра.
• MODULE_DESCRIPTION(): Кратко описывает функцию или предназначение этого LKM.
• MODULE_LICENSE(): Указывает лицензию(и), под которой выпущен этот модуль ядра.
• MODULE_VERSION(): Указывает строку версии (локальной) модуля ядра.

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

Эта информация, например, используется поставщиком для установления (открытых источников) лицензий, под которыми работает код, с помощью grep по выводу modinfo для всех установленных модулей ядра. (Это основные макросы модуля; будут рассмотрены и другие по мере продвижения.)

Точки входа и выхода

Не забывайте, модули ядра, в конце концов, это код ядра, работающий с привилегиями ядра. Это не приложение, и, следовательно, у него нет точки входа в виде знакомой нам функции main(). Это, конечно, вызывает вопрос: каковы точки входа и выхода модуля ядра? Обратите внимание на следующие строки в конце нашего простого модуля ядра:

module_init(helloworld_lkm_init);
module_exit(helloworld_lkm_exit);

Макросы module_{init|exit}() указывают на точки входа и выхода, соответственно. Параметр каждого из них - это указатель на функцию. С современными компиляторами C мы можем просто указать имя функции. Таким образом, в нашем коде это выглядит так:

• Функция helloworld_lkm_init() является точкой входа.
• Функция helloworld_lkm_exit() является точкой выхода.

Можно почти считать эти точки входа и выхода парой конструктор/деструктор для модуля ядра. Технически, это не совсем так, поскольку это не объектно-ориентированный код C++, а просто C. Тем не менее, это полезная аналогия, возможно.

Возвращаемые значения

Обратите внимание на сигнатуры функций инициализации и выхода, которые выглядят следующим образом:

static int __init <modulename>_init(void);
static void __exit <modulename>_exit(void);

Как хорошая практика программирования, мы использовали формат именования для функций как <modulename>_{init|exit}(), где <modulename> заменяется именем модуля ядра. Вы поймете, что эта конвенция именования - это всего лишь конвенция, которая технически не обязательна, но она интуитивна и полезна (помните, мы, люди, пишем код для того, чтобы люди его читали и понимали, а не машины). Очевидно, что ни одна из этих функций не принимает параметров.

Использование квалификатора static для обеих функций означает, что они приватны для этого модуля ядра. Это именно то, что мы хотим.

Теперь давайте перейдем к важной конвенции, которая применяется к возвращаемому значению функции инициализации модуля ядра.

Конвенция возврата 0/-E

Функция инициализации модуля ядра должна возвращать целое число, значение типа int; это ключевой аспект. Ядро Linux выработало определенный стиль или конвенцию, если хотите, относительно возвращаемых значений (то есть из пространства ядра, где находится и выполняется модуль, в процесс пользовательского пространства).

Чтобы вернуть значение, фреймворк LKM следует тому, что неформально называется конвенцией 0/-E:

• При успехе возвращается целочисленное значение 0.
• При неудаче возвращается отрицательное значение того, что вы хотите установить в глобальный неинициализированный целочисленный errno в пользовательском пространстве.

Обратите внимание, что errno - это глобальный целочисленный тип, находящийся в VAS процесса пользователя в его неинициализированном сегменте данных. За очень редкими исключениями, когда системный вызов Linux завершается неудачно, возвращается -1, и errno устанавливается в положительное значение, представляющее код ошибки или диагностику; эту работу выполняет “клеевая” кодовая база glibc на пути возврата системного вызова. Кроме того, значение errno является индексом в глобальной таблице сообщений об ошибках на английском языке (const char * sys_errlist[]); так функции, такие как perror(3), strerror_r и тому подобные, могут выводить диагностику ошибок. Кстати, вы можете найти полный список доступных вам кодов ошибок (errno) в следующих файлах заголовков (дерева исходного кода ядра): include/uapi/asm-generic/errnobase.h и include/uapi/asm-generic/errno.h.

Быстрый пример того, как вернуть значение из функции инициализации модуля ядра, поможет прояснить эту ключевую точку: предположим, что функция инициализации нашего модуля ядра пытается динамически выделить память ядра (детали API kmalloc() и т.д. будут рассмотрены в последующих главах, пожалуйста, пока игнорируйте это). Тогда мы могли бы написать код так:

[...]
ptr = kmalloc(87, GFP_KERNEL);
if (!ptr) {
    pr_warning("%s():%s():%d: kmalloc failed! Out of memory\n", __FILE__, __func__, __LINE__);
    return -ENOMEM;
}
[...]
return 0; /* успех */

Если выделение памяти действительно не удается (что маловероятно, но, эй, это может случиться в плохой день!), мы делаем следующее:

1. Сначала мы выводим предупреждение с помощью printk (не беспокойтесь, мы покроем эти синтаксические детали и многое другое о printk). В этом конкретном случае - “нет памяти” - считается педантичным и ненужным выводить сообщение. Ядро определенно выдаст достаточно диагностической информации, если когда-либо не удастся выделение памяти в пространстве ядра! Подробнее см. здесь: https://lkml.org/lkml/2014/6/10/382; мы делаем это здесь просто потому, что это ранняя стадия обсуждения и для непрерывности чтения.
2. Вернуть целочисленное значение -ENOMEM:
   • Слой, которому это значение будет возвращено в пользовательском пространстве, на самом деле это glibc; у него есть “клеевой” код, который умножает это значение на -1 и устанавливает глобальный целочисленный errno этим значением.
   • Теперь системный вызов [f]init_module() вернет -1, указывая на неудачу (потому что insmod фактически вызывает системный вызов finit_module() (или ранее init_module()), как вы скоро увидите).
   • errno будет установлен в ENOMEM, отражая тот факт, что вставка модуля ядра не удалась из-за сбоя выделения памяти.

Наоборот, фреймворк ожидает, что функция инициализации вернет значение 0 при успехе. На самом деле, в более старых версиях ядра, если не возвращать 0 при успехе, модуль ядра был бы немедленно и резко выгружен из памяти ядра. Сегодня такого удаления модуля не происходит; вместо этого ядро выдает предупреждающее сообщение о том, что возвращено подозрительное ненулевое значение. Более того, современные компиляторы обычно ловят тот факт, что вы не возвращаете значение, когда ожидается, выдавая сообщение об ошибке, подобное этому: error: no return statement in function returning non-void [-Werror=return-type].

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

Не включение макроса module_exit() в ваш модуль ядра делает невозможным его выгрузку (если не считать выключения или перезагрузки системы, конечно). Интересно… Я предлагаю вам попробовать это в качестве небольшого упражнения! Конечно, все не так просто: такое поведение, препятствующее выгрузке модуля, гарантировано только если ядро собрано с флагом CONFIG_MODULE_FORCE_UNLOAD установленным в Отключено (по умолчанию).

Макросы ERR_PTR и PTR_ERR

В обсуждении возвращаемых значений, вы теперь понимаете, что функция инициализации модуля ядра должна возвращать целое число. Что, если вы хотите вернуть вместо этого указатель? На помощь приходит встроенная функция ERR_PTR(), позволяя нам вернуть целое число, замаскированное под указатель, просто приведя его к типу void *. Это еще лучше: вы можете проверить на ошибку с помощью встроенной функции IS_ERR() (которая фактически только определяет, находится ли значение в диапазоне от -1 до -4095), кодирует отрицательное значение ошибки в указатель при помощи ERR_PTR(), и извлекает это значение из указателя с помощью противоположной функции PTR_ERR().

Как пример, рассмотрим следующий код вызываемой функции. На этот раз, в качестве примера, пусть функция myfunc() (пример) возвращает указатель (на структуру с именем mystruct), а не целое число:

struct mystruct * myfunc(void)

{
    struct mystruct *mys = NULL;
    mys = kzalloc(sizeof(struct mystruct), GFP_KERNEL);
    if (!mys)
        return ERR_PTR(-ENOMEM);
    [...]
    return mys;
}

Код вызывающей стороны следующий:

[...]
retp = myfunc();
if (IS_ERR(retp)) {
    pr_warn("myfunc() mystruct alloc failed, aborting...\n");
    stat = PTR_ERR(retp); /* устанавливает 'stat' в значение -ENOMEM */
    goto out_fail_1;
}
[...]
out_fail_1:
    return stat;
}

Для справки, встроенные функции ERR_PTR(), PTR_ERR(), и IS_ERR() находятся в файле заголовка ядра (include/linux/err.h). Пример использования этих функций можно найти здесь: https://elixir.bootlin.com/linux/v6.1.25/source/arch/x86/kernel/cpu/sgx/ioctl.c#L269 (и ERR_PTR() на строке 31).

Ключевые слова __init и __exit

Вспомните функции инициализации и очистки нашего простого модуля:

static int __init helloworld_lkm_init(void)
{
    [ ... ]
static void __exit helloworld_lkm_exit(void)
{
    [ ... ]

Остается вопрос: что именно означают макросы __init и __exit, которые мы видим в сигнатурах этих функций? Эти макросы просто указывают на атрибуты оптимизации памяти для компоновщика.

Макрос __init определяет секцию init.text для кода. Аналогично, любые данные, объявленные с атрибутом __initdata, помещаются в секцию init.data. Суть в том, что код и данные в функции инициализации используются ровно один раз во время инициализации.

После того как функция вызвана, она больше не будет вызвана; таким образом, после вызова весь код и данные в этих секциях освобождаются (с помощью free_initmem()). То же самое касается макроса __exit, хотя, конечно, это имеет смысл только для модулей ядра. После вызова функции очистки вся память освобождается. Если бы код был частью статического образа ядра (или если бы поддержка модулей была отключена), этот макрос не имел бы эффекта. Хорошо, но пока мы еще не объяснили некоторые практические моменты: как именно можно собрать новый модуль ядра, ввести его в память ядра и запустить, а затем выгрузить его, плюс несколько других операций, которые вы можете захотеть выполнить? Давайте обсудим это в следующем разделе.

Общие операции с модулями ядра

Теперь давайте углубимся в то, как именно вы можете собрать, загрузить и выгрузить модуль ядра. Кроме этого, мы также пройдемся по основам невероятно полезного API ядра printk(), деталям списка текущих загруженных модулей ядра с помощью lsmod, и удобному скрипту для автоматизации некоторых общих задач во время разработки модуля ядра. Итак, начнем!

Сборка модуля ядра

Здесь мы покажем шаг за шагом, как именно можно собрать и затем вставить наш самый первый модуль ядра в память ядра. Еще раз напомним: мы выполняли эти шаги на виртуальной машине Linux x86_64 (под Oracle VirtualBox 7.x), работающей под управлением дистрибутива Ubuntu 22.04 LTS (не то чтобы это сильно зависело от дистрибутива, который вы используете; общие шаги остаются теми же):

1. Перейдите в директорию с исходным кодом главы книги и в поддиректорию. Наш первый модуль ядра находится в своей собственной папке (как и должно быть!) под названием helloworld_lkm:

   cd <book-code-dir>/ch4/helloworld_lkm
   

2. Теперь проверьте базу кода: ```bash $ pwd