- Пишем простой модуль ядра Linux
- Захват Золотого Кольца-0
- Не для простых смертных
- Необходимые компоненты
- Установка среды разработки
- Начинаем
- Немного интереснее
- Тестирование улучшенного примера
- Заключение
- Kernel module (Русский)
- Contents
- Обзор
- Получение информации
- Автоматическое управление модулями
- Управление модулями вручную
- Настройка параметров модуля
- С помощью файлов в /etc/modprobe.d/
- С помощью командной строки ядра
- Создание псевдонимов
- Запрет загрузки
- С помощью файлов в /etc/modprobe.d/
- С помощью командной строки ядра
- How to Write Your Own Linux Kernel Module with a Simple Example
- I. Utilities to Manipulate Kernel Modules
- 1. lsmod – List Modules that Loaded Already
- 2. insmod – Insert Module into Kernel
- 3. modinfo – Display Module Info
- 4. rmmod – Remove Module from Kernel
- 5. modprobe – Add or Remove modules from the kernel
- II. Write a Simple Hello World Kernel Module
- 1. Installing the linux headers
- 2. Hello World Module Source Code
- 3. Create Makefile to Compile Kernel Module
- 4. Insert or Remove the Sample Kernel Module
- If you enjoyed this article, you might also like..
Пишем простой модуль ядра Linux
Захват Золотого Кольца-0
Linux предоставляет мощный и обширный API для приложений, но иногда его недостаточно. Для взаимодействия с оборудованием или осуществления операций с доступом к привилегированной информации в системе нужен драйвер ядра.
Модуль ядра Linux — это скомпилированный двоичный код, который вставляется непосредственно в ядро Linux, работая в кольце 0, внутреннем и наименее защищённом кольце выполнения команд в процессоре x86–64. Здесь код исполняется совершенно без всяких проверок, но зато на невероятной скорости и с доступом к любым ресурсам системы.
Не для простых смертных
Написание модуля ядра Linux — занятие не для слабонервных. Изменяя ядро, вы рискуете потерять данные. В коде ядра нет стандартной защиты, как в обычных приложениях Linux. Если сделать ошибку, то повесите всю систему.
Ситуация ухудшается тем, что проблема необязательно проявляется сразу. Если модуль вешает систему сразу после загрузки, то это наилучший сценарий сбоя. Чем больше там кода, тем выше риск бесконечных циклов и утечек памяти. Если вы неосторожны, то проблемы станут постепенно нарастать по мере работы машины. В конце концов важные структуры данных и даже буфера могут быть перезаписаны.
Можно в основном забыть традиционные парадигмы разработки приложений. Кроме загрузки и выгрузки модуля, вы будете писать код, который реагирует на системные события, а не работает по последовательному шаблону. При работе с ядром вы пишете API, а не сами приложения.
У вас также нет доступа к стандартной библиотеке. Хотя ядро предоставляет некоторые функции вроде printk (которая служит заменой printf ) и kmalloc (работает похоже на malloc ), в основном вы остаётесь наедине с железом. Вдобавок, после выгрузки модуля следует полностью почистить за собой. Здесь нет сборки мусора.
Необходимые компоненты
Прежде чем начать, следует убедиться в наличии всех необходимых инструментов для работы. Самое главное, нужна машина под Linux. Знаю, это неожиданно! Хотя подойдёт любой дистрибутив Linux, в этом примере я использую Ubuntu 16.04 LTS, так что в случае использования других дистрибутивов может понадобиться слегка изменить команды установки.
Во-вторых, нужна или отдельная физическая машина, или виртуальная машина. Лично я предпочитаю работать на виртуальной машине, но выбирайте сами. Не советую использовать свою основную машину из-за потери данных, когда сделаете ошибку. Я говорю «когда», а не «если», потому что вы обязательно подвесите машину хотя бы несколько раз в процессе. Ваши последние изменения в коде могут ещё находиться в буфере записи в момент паники ядра, так что могут повредиться и ваши исходники. Тестирование в виртуальной машине устраняет эти риски.
И наконец, нужно хотя бы немного знать C. Рабочая среда C++ слишком велика для ядра, так что необходимо писать на чистом голом C. Для взаимодействия с оборудованием не помешает и некоторое знание ассемблера.
Установка среды разработки
На Ubuntu нужно запустить:
Устанавливаем самые важные инструменты разработки и заголовки ядра, необходимые для данного примера.
Примеры ниже предполагают, что вы работаете из-под обычного пользователя, а не рута, но что у вас есть привилегии sudo. Sudo необходима для загрузки модулей ядра, но мы хотим работать по возможности за пределами рута.
Начинаем
Приступим к написанию кода. Подготовим нашу среду:
Запустите любимый редактор (в моём случае это vim) и создайте файл lkm_example.c следующего содержания:
Мы сконструировали самый простой возможный модуль, рассмотрим подробнее самые важные его части:
- В include перечислены файлы заголовков, необходимые для разработки ядра Linux.
- В MODULE_LICENSE можно установить разные значения, в зависимости от лицензии модуля. Для просмотра полного списка запустите:
Впрочем, пока мы не можем скомпилировать этот файл. Нужен Makefile. Такого базового примера пока достаточно. Обратите внимание, что make очень привередлив к пробелам и табам, так что убедитесь, что используете табы вместо пробелов где положено.
Если мы запускаем make , он должен успешно скомпилировать наш модуль. Результатом станет файл lkm_example.ko . Если выскакивают какие-то ошибки, проверьте, что кавычки в исходном коде установлены корректно, а не случайно в кодировке UTF-8.
Теперь можно внедрить модуль и проверить его. Для этого запускаем:
Если всё нормально, то вы ничего не увидите. Функция printk обеспечивает выдачу не в консоль, а в журнал ядра. Для просмотра нужно запустить:
Вы должны увидеть строку “Hello, World!” с меткой времени в начале. Это значит, что наш модуль ядра загрузился и успешно сделал запись в журнал ядра. Мы можем также проверить, что модуль ещё в памяти:
Для удаления модуля запускаем:
Если вы снова запустите dmesg, то увидите в журнале запись “Goodbye, World!”. Можно снова запустить lsmod и убедиться, что модуль выгрузился.
Как видите, эта процедура тестирования слегка утомительна, но её можно автоматизировать, добавив:
в конце Makefile, а потом запустив:
для тестирования модуля и проверки выдачи в журнал ядра без необходимости запускать отдельные команды.
Теперь у нас есть полностью функциональный, хотя и абсолютно тривиальный модуль ядра!
Немного интереснее
Копнём чуть глубже. Хотя модули ядра способны выполнять все виды задач, взаимодействие с приложениями — один из самых распространённых вариантов использования.
Поскольку приложениям запрещено просматривать память в пространстве ядра, для взаимодействия с ними приходится использовать API. Хотя технически есть несколько способов такого взаимодействия, наиболее привычный — создание файла устройства.
Вероятно, раньше вы уже имели дело с файлами устройств. Команды с упоминанием /dev/zero , /dev/null и тому подобного взаимодействуют с устройствами “zero” и “null”, которые возвращают ожидаемые значения.
В нашем примере мы возвращаем “Hello, World”. Хотя это не особенно полезная функция для приложений, она всё равно демонстрирует процесс взаимодействия с приложением через файл устройства.
Вот полный листинг:
Тестирование улучшенного примера
Теперь наш пример делает нечто большее, чем просто вывод сообщения при загрузке и выгрузке, так что понадобится менее строгая процедура тестирования. Изменим Makefile только для загрузки модуля, без его выгрузки.
Теперь после запуска make test вы увидите выдачу старшего номера устройства. В нашем примере его автоматически присваивает ядро. Однако этот номер нужен для создания нового устройства.
Возьмите номер, полученный в результате выполнения make test , и используйте его для создания файла устройства, чтобы можно было установить коммуникацию с нашим модулем ядра из пространства пользователя.
(в этом примере замените MAJOR значением, полученным в результате выполнения make test или dmesg )
Параметр c в команде mknod говорит mknod, что нам нужно создать файл символьного устройства.
Теперь мы можем получить содержимое с устройства:
или даже через команду dd :
Вы также можете получить доступ к этому файлу из приложений. Это необязательно должны быть скомпилированные приложения — даже у скриптов Python, Ruby и PHP есть доступ к этим данным.
Когда мы закончили с устройством, удаляем его и выгружаем модуль:
Заключение
Надеюсь, вам понравились наши шалости в пространстве ядра. Хотя показанные примеры примитивны, эти структуры можно использовать для создания собственных модулей, выполняющих очень сложные задачи.
Просто помните, что в пространстве ядра всё под вашу ответственность. Там для вашего кода нет поддержки или второго шанса. Если делаете проект для клиента, заранее запланируйте двойное, если не тройное время на отладку. Код ядра должен быть идеален, насколько это возможно, чтобы гарантировать цельность и надёжность систем, на которых он запускается.
Источник
Kernel module (Русский)
Модули ядра — это отдельные кусочки кода, которые могут быть загружены и выгружены из ядра по мере необходимости. Они расширяют функциональность ядра без необходимости перезагрузки системы.
Contents
Обзор
Чтобы создать модуль ядра, вы можете прочитать The Linux Kernel Module Programming Guide. Модуль можно сконфигурировать как вкомпилированный, а можно как загружаемый. Чтобы иметь возможность динамически загружать или выгружать модуль, его необходимо сконфигурировать как загружаемый модуль в настройке ядра (в этом случае строка, относящаяся к модулю должна быть отмечена буквой M ).
Модули хранятся в /usr/lib/modules/kernel_release . Чтобы узнать текущую версию вашего ядра, используйте команду uname -r .
Получение информации
Чтобы узнать, какие модули ядра загружены в настоящий момент:
Чтобы показать информацию о модуле:
Чтобы вывести список опций, с которыми загружен модуль:
Чтобы отобразить настройки для всех модулей:
Чтобы отобразить настройки для отдельного модуля:
Чтобы узнать зависимости модуля (или его псевдонима), включая сам модуль:
Автоматическое управление модулями
Сегодня все необходимые загрузки модулей делаются автоматически с помощью udev, поэтому если вам не нужно загружать какие-либо модули, не входящие в стандартное ядро, вам не придётся прописывать модули, требующиеся для загрузки в каком-либо конфигурационном файле. Однако, бывают случаи, когда вам необходимо загружать свой модуль в процессе загрузки или наоборот не загружать какой-то стандартный модуль, чтобы ваш компьютер правильно функционировал.
Чтобы дополнительные модули ядра загружались автоматически в процессе загрузки, создаются статические списки в конфигурационных файлах в директории /etc/modules-load.d/ . Каждый конфигурационный файл называется по схеме /etc/modules-load.d/
.conf . Эти конфигурационные файлы содержат список названий модулей ядра, которые необходимо грузить, разделённых переносом строки. Пустые строки и строки, в которых первым непробельным символом является # или ; , игнорируются.
Смотрите modules-load.d(5) для дополнительной информации.
Управление модулями вручную
Управление модулями ядра производится с помощью утилит, предоставляемых пакетом kmod . Вы можете использовать эти утилиты вручную.
Загрузка модуля из другого места (для тех модулей, которых нет в /lib/modules/$(uname -r)/ ):
Альтернативный вариант выгрузки модуля:
Настройка параметров модуля
Чтобы передать параметр модулю ядра, вы можете воспользоваться конфигурационным файлом в modprobe или использовать командную строку ядра.
С помощью файлов в /etc/modprobe.d/
Файлы в директории /etc/modprobe.d/ можно использовать для передачи настроек модуля в udev, который через modprobe управляет загрузкой модулей во время загрузки системы. Конфигурационные файлы в этой директории могут иметь любое имя, оканчивающееся расширением .conf . Синтаксис следующий:
С помощью командной строки ядра
Если модуль вкомпилирован в ядро, вы также можете передать параметры модулю с помощью командной строки ядра. Для всех стандартных загрузчиков, подойдёт следующий синтаксис:
Просто добавьте это в загрузчике в строку с ядром, как описано в параметрах ядра.
Создание псевдонимов
Псевдонимы (алиасы) — это альтернативные названия для модуля. Например: alias my-mod really_long_modulename означает, что вы можете использовать modprobe my-mod вместо modprobe really_long_modulename . Вы также можете использовать звёздочки в стиле shell, то есть alias my-mod* really_long_modulename будет иметь тот же эффект, что и modprobe my-mod-something . Создайте алиас:
У некоторых модулей есть алиасы, которые используются для их автоматической загрузки, когда они потребуются определённой программе. Отключение этих алиасов может предотвратить их автоматическую загрузку, при этом остаётся возможность из загрузки вручную.
Запрет загрузки
В терминах модулей ядра blacklisting означает механизм, предотвращающий загрузку какого-то модуля. Это может понадобиться, например если вам не нужна работа какого-то оборудования или если загрузка данного модуля вызывает проблемы: например, могут быть два модуля ядра, которые пытаются управлять одним и тем же оборудованием, и их совместная загрузка приводит к конфликту.
Некоторые модули загружаются как часть initramfs. Команда mkinitcpio -M напечатает все автоматически обнаруженные модули: для предотвращения initramfs от загрузки каких-то из этих модулей, занесите их в чёрный список в /etc/modprobe.d/modprobe.conf . Команда mkinitcpio -v отобразит все модули, которые необходимы некоторым хукам (например, filesystems хук, block хук и т.д.). Не забудьте добавить этот .conf файл в секцию FILES в /etc/mkinitcpio.conf , если вы этого ещё не сделали, пересоберите initramfs после того, как вы запретили загрузку модулей, а затем перезагрузитесь.
С помощью файлов в /etc/modprobe.d/
Создайте .conf файл в /etc/modprobe.d/ и добавьте строку для каждого модуля, который вы хотите запретить, используя ключевое слово blacklist . Например, если вы хотите запретить загружать модуль pcspkr :
Можно изменить такое поведение. Команда install заставляет modprobe запускать вашу собственную команду вместо вставки модуля в ядро как обычно. Поэтому вы можете насильно сделать так, чтобы модуль никогда не загружался:
Это запретит данный модуль и все модули, зависящие от него.
С помощью командной строки ядра
Вы также можете запрещать модули из загрузчика.
Источник
How to Write Your Own Linux Kernel Module with a Simple Example
What are kernel modules?
Kernel modules are piece of code, that can be loaded and unloaded from kernel on demand.
Kernel modules offers an easy way to extend the functionality of the base kernel without having to rebuild or recompile the kernel again. Most of the drivers are implemented as a Linux kernel modules. When those drivers are not needed, we can unload only that specific driver, which will reduce the kernel image size.
The kernel modules will have a .ko extension. On a normal linux system, the kernel modules will reside inside /lib/modules/ /kernel/ directory.
Earlier we discussed how to compile a kernel from the source.
This tutorial explains how to write a Kernel module using a simple Hello World example.
I. Utilities to Manipulate Kernel Modules
1. lsmod – List Modules that Loaded Already
lsmod command will list modules that are already loaded in the kernel as shown beblow.
2. insmod – Insert Module into Kernel
insmod command will insert a new module into the kernel as shown below.
3. modinfo – Display Module Info
modinfo command will display information about a kernel module as shown below.
4. rmmod – Remove Module from Kernel
rmmod command will remove a module from the kernel. You cannot remove a module which is already used by any program.
5. modprobe – Add or Remove modules from the kernel
modprobe is an intelligent command which will load/unload modules based on the dependency between modules. Refer to modprobe commands for more detailed examples.
II. Write a Simple Hello World Kernel Module
1. Installing the linux headers
You need to install the linux-headers-.. first as shown below. Depending on your distro, use apt-get or yum.
2. Hello World Module Source Code
Next, create the following hello.c module in C programming language.
Warning: All kernel modules will operate on kernel space, a highly privileged mode. So be careful with what you write in a kernel module.
3. Create Makefile to Compile Kernel Module
The following makefile can be used to compile the above basic hello world kernel module.
Use the make command to compile hello world kernel module as shown below.
The above will create hello.ko file, which is our sample Kernel module.
4. Insert or Remove the Sample Kernel Module
Now that we have our hello.ko file, we can insert this module to the kernel by using insmod command as shown below.
When a module is inserted into the kernel, the module_init macro will be invoked, which will call the function hello_init. Similarly, when the module is removed with rmmod, module_exit macro will be invoked, which will call the hello_exit. Using dmesg command, we can see the output from the sample Kernel module.
Please note that printk is a function which is defined in kernel, and it behaves similar to the printf in the IO library. Remember that you cannot use any of the library functions from the kernel module.
Now you have learned the basics to create your own Linux Kernel module.
If you enjoyed this article, you might also like..
|
|
Thanks.
Very useful article
Thanks again
Very nice explaination
Good article, but one slight adjustment:
You suggest creating the file helloworld.c, but specify hello.o in the Makefile. My code wouldn’t compile because of this – I had to put “obj-m += helloworld.o” in the Makefile before it would work.
Once I figured that out, Bob’s your uncle, thanks for posting this.
Simply incredible article!
really very useful, your website it’s wonderful. i learning a lot. thanks
Great article!!
One suggestion would be maybe a 1 paragraph to describe when you would write a kernel module vs running the same code in user space.
This is great, all this geek stuff just keeps getting better. Thank you!
Awesome article !! Thanks for sharing such stuff.
Thanks, looks useful.
Great Article, but I have to agree with Bob. An explanation when you would write a kernel module instead of creating a program in user space would be a good idea.
Great…keep it up.
I’ve tried on two Ubuntu boxes and both have build-essentials and linux-headers (linux-headers-2.6.32-45-generic) installed but no linux/module.h available. I can see it in /usr/src/linux-headers-2.6.32-45-generic/include/linux/module.h but …
Never mind, or, rather, I have a Makefile problem – running:
$ make -C /lib/modules/$(uname -r)/build M=$
works just fine.
Thanks.
Just make sure you have tabs in the makefile, or you’ll get
“make: Nothing to be done for `all’ ”
e.g
all:
make −C /lib/modules/$(shell uname −r)/build M=$(PWD) modules
clean:
make −C /lib/modules/$(shell uname −r)/build M=$(PWD) clean
i am executing the make command on cent os i am getting error like
make -C /lib/modules/2.6.32-358.el6.i686/build M=/root modules
make: *** /lib/modules/2.6.32-358.el6.i686/build: No such file or directory. Stop.
make: *** [all] Error 2
Hi,thanks for the article. I have one doubt,while trying out various things I found that when I comment out module_init and module_exit, the code works fine still and the module gets loaded. But you have said those two are used to call the entry and exit funcs. HOW DID IT WORK THEN??
Also,I am not using init_module or cleanup_module(pre-defined ones..)
When you do insmod, the module will be loaded into kernel, but the entry function will not be called, and without that there is no use of a module. In my opinion, kernel module without module_init will be of no use.
Only when you do module_init, the entry function will be called, and the module can start performing its operations.
Hi, yeah got it figured already when I looked for the logs… there was no entry without those two… Thanks. 🙂
but it needs “shell uname” changed “uname”, and $(PWD) to `pwd`. Because PWD may not have been set by user in shell.
above suggestion is for doing compilation without makefile OR shell specific settings. As many users have posted about makefile doing nothing.
Thanx. It helped !
how to clear the eror all is up to data.while running make i am getting this error plz help me how to solve this error……i am using 3.13.1 kernel version……while updating headres it giving some errors.how to clear these errors
Hello sir,
I have one doubt, please ans my doubt. why u used __init and __exit why you not use _init and _exit. is there any standard to write like that or simply you have taken example.
heyy.. frineds. I am a newbie here for kernel programming. Unfortunately getting this error.
cc makefile.c -o makefile
makefile.c:1:4: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘-’ token
obj-m += hello.o
^
make: *** No targets specified and no makefile found. Stop.
Er, you need to reread the article
cc makefile.c -o makefile
isn’t correct – there isn’t a makefile.c there’s a hello.c. You use “make” and the makefile as a “recipe” to handle the details of compling the hello.c C code into an executable. You’ll have two text files in your dir makefile and hello.c and then you just type “make”, it read makefile and then handles the calling “cc” to do the actual compile.
If i am to compile the Kernel Module for say beaglebone how do i do it? What would the makefile need to look like?
realy helpfull
thanks
Now, thats what I call a smooth howto.
Thanks
After I do the insmod hello.ko, I get the following message:-
insmod: error inserting ‘hello.ko’: -1 Operation not permitted.
Please advice on what needs to be done or where I went wrong.
hello anand,
probably you tried to insmod as an unprivileged user
Thanks Lakshmanan. This helped a lot.
Cheers!
What happens if you change the name of Makefile to compile your kernel module? It does not work in that case.
Really great explanation . Helped me well ! Thanks
Great article for people to get into kernel programming.
Just 1 remark:
There’s no reason to use the __init and __exit macro’s in loadable modules and it only makes your code unnecessarily complex 🙂
These have no effect for modules and are only to cleanup memory after builtin drivers.
Source: Kernel documentation
This demonstrates a feature of kernel 2.2 and later. Notice the change in the definitions of the init and cleanup functions. The __init macro causes the init function to be discarded and its memory freed once the init function finishes for built-in drivers, but not loadable modules. If you think about when the init function is invoked, this makes perfect sense.
The __exit macro causes the omission of the function when the module is built into the kernel, and like __exit, has no effect for loadable modules. Again, if you consider when the cleanup function runs, this makes complete sense.
Источник