Вот и пришло время второй статьи из цикла о написании драйверов под Windows. Сейчас я тебя немного расстрою: в предыдущей статье я обещала, что в этой мы приступим собственно к практике. Но данная статья это, скорее, "полупрактика". Глупо "с места в карьер" бросаться разрабатывать драйвера режима ядра
(так как, если ты не забыл, в данном цикле мы разбираем именно этот тип драйверов), хотя бы поверхностно не изучив особенности и приёмы программирования в режиме ядра, что мы и сделаем в первой части этой статьи. Ну а во второй мы наконец - то разберём структуру настоящего драйвера под Windows
(Legacy и немного WDM) : его основные функции, их взаимодействие, а также параметры, принимаемые ими. Так что к третьей статье этого цикла ты уже, надо думать, будешь основательно подготовлен к написанию своего первого драйвера. Начинаем.
Особенности и приёмы программирования в режиме ядра
Программирование в режиме ядра имеет массу особенностей, для прикладников очень непривычных, а для новичков довольно сложных. Во-первых, у режима ядра своё, отличное от такового в пользовательском режиме, API. Кроме того, для кода, выполняющегося в режиме ядра, имеет очень большое значение его уровень IRQL, так как приложениям, выполняющимся на высоких уровнях IRQL, недоступны многие функции, к которым имеют доступ приложения низких IRQL уровней, и наоборот. Всё это необходимо учитывать.
Во-вторых, в режиме ядра есть свои дополнительные описатели типов. Полный их список можно найти в заголовочном файле ntdef.h. Его содержание примерно таково:
typedef unsigned char USHAR
typedef unsigned short USHORT
typedef unsigned long ULONG
............
Зачем это нужно? Ну, во-первых, для красоты... тьфу, для унификации стиля классических C - типов данных и нововведённых - таких, как WCHAR
(двухбайтный Unicode символ), LARGE_INTEGER (который, на самом деле, является объединением) и т.д. А также для унификации исходников для 32 - разрядных платформ и надвигающихся 64 - разрядных.
В исходниках драйверов часто встречаются макроопределения
IN, OUT, OPTIONAL. Что они означают? А ровным счётом ничего, и введены они только для повышения удобочитаемости исходника. OPTIONAL обозначает необязательные параметры, IN - параметры, передаваемые внутрь функции, например, OUT - соответственно, наоборот. А вот IN OUT означает, что параметр передаётся внутрь функции, а затем возвращается из неё обратно.
Есть изменения и в типах возвращаемых значений функций. Ты наверняка знаешь, что C-ишные функции либо не возвращают значения
(void), либо возвращают значение определённого типа
(char, int etc). При программировании драйверов ты столкнёшься с ещё одним типом - NT_STATUS. Этот тип включает в себя информацию о коде завершения функции
(определение этого типа можно посмотреть в файле ntdef.h). NT_STATUS является переопределённым типом long integer. Неотрицательные значения переменных этого типа
соответствуют успешному завершению функции, отрицательные - наоборот
(файл NTSTATUS содержит символьные обозначения всех кодов возврата). Сообщение об удачном завершении имеет код 0 и символьное обозначение STATUS_SUCCESS. Остальные коды возврата, соответствующие разнообразным вариантам ошибок, транслируются в системные коды ошибок и передаются вызывающей программе. Для работы с типом NT_STATUS существует несколько макроопредений
(описанные в файле ntdef.h), например NT_SUCCESS(), проверяющий код возврата на успешность завершения.
Функции драйвера, за исключением DriverEntry (главная процедура драйвера, подробнее см. во второй части статьи), могут называться как угодно, тем не менее, существуют определённые "правила хорошего тона" при разработке драйверов, в том числе и для именования процедур: например, все функции, относящиеся к HAL, желательно предварять префиксом HAL и т.д. Сама Microsoft практически постоянно следует этому правилу. А имена типов данных и макроопределения в листингах DDK написаны сплошь заглавными буквами. Советую тебе поступать также при разработке своих драйверов. Это и в самом деле во много раз повышает удобство работы с листингом.
А теперь, чтобы тебе стали более или менее понятны основные различия между программированием в пользовательском и системном режимах, расскажу об основных функциях для работы с памятью и реестром в режиме ядра.
Начнём с функций для работы с памятью, а для начала поговорим собственно об устройстве и работе с памятью в Windows. Единое 4-х гигабайтное адресное пространство памяти Windows
(я имею в виду 32-х разрядные версии Windows) делится на две части: 2 гигабайта для пользовательского пространства и 2 гигабайта для системного. 2 гигабайта системного пространства доступны для всех потоков режима ядра. Системное адресное пространство делится на следующие части:
Видов адресов в режиме ядра три: физические
(реально указывающие на область физической памяти), виртуальные
(которые перед использованием транслируются в физические), и логические
(используемые HAL уровнем при общении с устройствами; он же и отвечает за работу с такими адресами). Функции режима ядра, отвечающие за выделение и освобождение виртуальной памяти, отличаются от таковых в пользовательском режиме. Также, находясь на уровне режима ядра, становится возможным использовать функции выделения и освобождения физически непрерывной памяти. Разберём все эти функции поподробнее.
1) PVOID ExAllocatePool (уровень IRQL, на котором может выполняться эта функция - < DISPATCH_LEVEL) - выделяет область памяти. Принимает два параметра: параметр
(POOL_TYPE) , в котором содержится значение, означающее, какого типа область памяти нужно выделить: PagedPool - страничная, NonPagedPool - нестраничная
(в этом случае функцию можно вызвать с любого IRQL уровня). Второй параметр
(ULONG) - размер запрашиваемой области памяти. Функция возвращает указатель на выделенную область памяти, и NULL, если выделить память не удалось.
2) VOID ExFreePool (IRQL<DISPATCH_LEVEL) - освобождает область памяти. Принимает параметр
(PVOID) - указатель на освобождаемую область памяти. Если высвобождается нестраничная память, то данная функция может быть вызвана с
DISPATCH_LEVEL. Возвращаемое значение - void.
3) PVOID MmAllocateContiguousMemory (IRQL==PASSIVE_LEVEL) - выделяет физически непрерывную область памяти. Принимает два параметра. Первый параметр
(ULONG) - размер запрашиваемой области памяти, второй - параметр
(PHYSICAL_ADDRESS), означающий верхний предел адресов для запрашиваемой области. Возвращаемое значение: виртуальный адрес выделенной области памяти или NULL
(при неудаче).
4) VOID MmFreeContiguousMemory (IRQL==PASSIVE_LEVEL) - освобождает физически непрерывную область памяти. Принимает единственный параметр
(PVOID) - указатель на область памяти, выделенную ранее с использованием функции MmAllocateContiguousMemory. Возвращаемое значение -
void.
5) BOOLEAN MmIsAddressValid (IRQL<=DISPATCH_LEVEL) - делает проверку виртуального адреса. Принимает параметр
(PVOID) - виртуальный адрес, нуждающийся в проверке. Функция возвращает TRUE, если адрес "валидный"
(т.е. присутствует в виртуальной памяти), и FALSE - в противном случае.
6) PHYSICAL_ADDRESS MmGetPhysicalAddress (IRQL - любой) - определяет физический адрес по виртуальному. Принимает параметр
(PVOID), содержащий анализируемый виртуальный адрес. Возвращаемое значение - полученный физический адрес.
Основные функции для работы с памятью рассмотрели, перейдём к таковым для работы с реестром. Сначала поговорим о функциях доступа к реестру, предоставляемых диспетчером ввода - вывода, потом о драйверных функциях прямого доступа к реестру, а затем о самом богатом по возможностям и удобству семействе функций для работы с реестром -
Zw~.
Драйверные функции, предоставляемые диспетчером ввода - вывода.
1) IoRegisterDeviceInterface - данная функция регистрирует интерфейс устройства. Диспетчер ввода - вывода создаёт подразделы реестра для всех зарегистрированных интерфейсов. После этого можно создавать и хранить в этом подразделе нужные драйверу параметры с помощью вызова функции IoOpenDeviceInterfaceRegistryKey, которая возвращает дескриптор доступа к подразделу реестра для зарегистрированного интерфейса устройства.
2) IoGetDeviceProperty - данная функция запрашивает из реестра установочную информацию об устройстве.
3) IoOpenDeviceRegistryKey - возвращает дескриптор доступа к подразделу реестра для драйвера или устройства по указателю на его объект.
4) IoSetDeviceInterfaceState - с помощью данной функции можно разрешить или запретить доступ к зарегистрированному интерфейсу устройства. Компоненты системы могут получать доступ только к разрешённым интерфейсам.
Драйверные функции для прямого доступа к реестру.
1) RtlCheckRegistryKey - проверяет, существует ли указанный
подраздел внутри подраздела, переданного первым параметром. Что и каким
образом передавать в первом параметре - в рамках статьи всё не перечислить, отсылаю к ntddk.h и wdm.h. Если существует - возвращается
STATUS_SUCCESS.
2) RtlCreateRegistryKey - создаёт подраздел внутри раздела реестра, указанного вторым параметром. Далее - всё то же самое, что и у
RtlCheckRegistryKey.
3) RtlWriteRegistryValue - записывает значение параметра реестра. Первый параметр - куда пишем, второй - в какой подраздел
(если его нет, то он будет создан), а третий - какой параметр создаём.
4) RtlDeleteRegistryValue - удаляет параметр из подраздела. Параметры те же самые, что и у RtlWriteRegistryValue
(только с необходимыми поправками, конечно).
5) RtlQueryRegistryValues - данная функция позволяет за один вызов получить значения сразу нескольких параметров указанного подраздела.
И напоследок функции для работы с реестром семейства
Zw~.
1) ZwCreateKey - открывает доступ к подразделу реестра. Если такового нет - создаёт новый. Возвращает дескриптор открытого объекта.
2) ZwOpenKey - открывает доступ к существующему подразделу реестра.
3) ZwQueryKey - возвращает информацию о подразделе.
4) ZwEnumerateKey - возвращает информацию о вложенных подразделах уже открытого ранее подраздела.
5) ZwEnumerateValueKey - возвращает информацию о параметрах и их значениях открытого ранее подраздела.
6) ZwQueryValueKey - возвращает информацию о значении параметра в открытом ранее разделе реестра. Полнота возвращаемой информации определяется третьим параметром, передаваемым функции, который может принимать следующие значения
(дополнительные разъяснения не требуются, так как они имеют "говорящие" имена):
KeyValueBasicInformation, KeyValuePartialInformation и KeyValueFullInformation.
7) ZwSetValueKey - создаёт или изменяет значение параметра в открытом ранее подразделе реестра.
8) ZwFlushKey - принудительно сохраняет на диск изменения, сделанные в открытых функциями ZwCreateKey и ZwSetValueKey подразделах.
9) ZwDeleteKey - удаляет открытый подраздел из реестра.
10) ZwClose - закрывает дескриптор открытого ранее подраздела реестра, предварительно сохранив сделанные изменения на диске.
Практически все вышеперечисленные функции для работы с реестром должны вызываться с уровня IRQL
PASSIVE_LEVEL.
Думаю, пока достаточно. Конечно, у всех вышеперечисленных функций есть масса нюансов в применении. Да и вообще функций режима ядра - великое множество, их ничуть не меньше, чем в пользовательском режиме. Но моя задача была не рассказать обо всех API - функциях режима ядра
(что даже в рамках цикла невозможно сделать), а продемонстрировать отличия функций режима ядра, от таковых в пользовательском режиме, и хоть немного рассказать о нюансах их применения
(взять, к примеру, то, что в пользовательском режиме не имеет значения, в потоке какого приоритета будет выполняться приложение: оно будет иметь такой же полный доступ ко всем API функциям пользовательского режима, как и любые другие приложения; на уровне ядра, как ты только что, убедился, это не так). Ну а за более или менее полным списком и описанием всех этих API - функций советую обратиться к библии Гарри Нэббета.
Ну вот и всё, теперь ты готов к разговору о структуре драйвера, который мы сейчас и начнём.
Структура драйвера
Я уже говорила, что драйвер фактически можно представить как довольно-таки обычную dll-ку уровня ядра. Таким образом, далее можно представить драйвер просто как набор процедур, периодически вызываемых внешними программами. Несмотря на то, что процедуры драйверов для разных устройств сильно отличаются, есть общая структура и общие функции для всех драйверов. Главные из них мы сейчас и рассмотрим.
Входная точка любого драйвера - функция DriverEntry
(по поводу названий вообще всех функций - смотри соглашение в первой части статьи), которая фактически играет ту же самую роль для драйвера, что и main для проги на C. Эта функция вызывается при загрузке драйвера
(неважно, загружается ли он динамически или при запуске системы). Данная функция выполняет некоторые действия, нужные для нормальной работы драйвера
(например, регистрирует в специальном массиве адреса всех остальных функций драйвера, чтобы диспетчер ввода - вывода мог вызывать их по этим адресам). Если это не WDM драйвер, то в этой функции происходит локализация обслуживаемого оборудования, выделение и/или подтверждение используемых аппаратных ресурсов, выдача видимых для системы имён всем найденным обслуживаемым устройствам и т.д. WDM драйвера эту работу перекладывают на функцию AddDevice. Функция DriverEntry может вызываться с уровня IRQL == PASSIVE_LEVEL. Функция возвращает значение типа NTSTATUS, и принимает два параметра: адрес объекта драйвера
(PDRIVER_OBJECT) и путь в реестре к подразделу драйвера
(PUNICODE_STRING). Получив от диспетчера ввода - вывода указатель на структуру DRIVER_OBJECT драйвер должен заполнить в ней некоторые поля:
1) Поле DriverUnload - для регистрации собственной функции Unload, вызываемой при выгрузке драйвера. Подробнее о ней.
Эта функция вызывается только при динамической выгрузке драйвера
(т.е. происшедшей не в результате завершения работы системы). Legacy драйвера в этой функции выполняют полное освобождение всех занятых драйвером системных ресурсов. WDM драйвера выполняют такое освобождение в функции RemoveDevice при удалении каждого устройства
(если драйвер обслуживает несколько устройств). Функция Unload вызывается с уровня IRQL PASSIVE_LEVEL, принимает единственный параметр
(PDRIVER_OBJECT) - указатель на объект драйвера, и возвращает
void.
2) Поле DriverStartIo - для регистрации собственной функции
StartIo. Вкратце, регистрация функции StartIo нужна для участия в System Queuing - создании очередей необработанных запросов системными средствами, в отличие от DriverQueuing - когда то же самое реализуется средствами самого драйвера.
3) Поле AddDevice в подструктуре DriverExtension - для регистрации WDM драйвером своей процедуры
AddDevice.
4) Поле MajorFunction - для регистрации драйвером точек входа в свои рабочие процедуры.
Бывают ситуации, когда при первоначальной загрузке драйвер не может до конца окончить процедуру инициализации
(например, если необходимы какие-либо системные объекты или другие драйвера, ещё не загруженные). В этом случае драйвер регистрирует свою процедуру для завершения инициализации позднее. Регистрация этой процедуры выполняется вызовом IoRegisterDriverReinitialization с уровня IRQL PASSIVE_LEVEL, принимающей следующие параметры: указатель на объект драйвера
(PDRIVER_OBJECT), указатель на процедуру реинициализации, предоставляемую драйвером
(PDRIVER_REINITIALIZE) и контекстный указатель, получаемый регистрируемой функцией при вызове, и возвращающей
void.
Если выгрузка драйвера происходит в результате завершения работы системы, то функция Unload не вызывается. Это понятно: при выключении системы можно не заботиться об освобождении памяти и т.д. Поэтому вызывается функция Shutdown, которая просто предоставляет драйверу возможность оставить устройство в приемлемом состоянии покоя.
Может случиться так, что твоему драйверу необходимо будет получить управление при крахе системы. В этом случае ему нужно зарегистрировать callback процедуру Bugcheck. Если драйвер правильно выполнил регистрацию этой функции, то он будет вызван во время исполнения crash процесса.
Я перечислила основные функции драйвера для его загрузки и выгрузки. Теперь перейдём к рабочим процедурам драйвера.
Поговорим о следующих рабочих процедурах: обслуживания ввода - вывода
(включающих в себя процедуры передачи данных и обслуживания прерываний), callback процедуры для синхронизации доступа к объектам и некоторые другие.
Все драйверы должны иметь обработчик CreateDispatch, обрабатывающий пользовательский запрос CreateFile. Если драйверу нужно обрабатывать пользовательский запрос CloseHandle, то он должен иметь обработчик
CloseDispatch.
Перейдём к процедурам передачи данных. Это обработчики пользовательских запросов ReadFile, WriteFile и
DeviceIoControl.
Процедуру StartIo я уже рассмотрела, поэтому перейдём к процедуре обслуживания прерываний
(ISR - Interrupt Service Routine, напоминаю на всякий случай). Данная процедура вызвается диспетчером прерываний ядра
(Kernel`s Interrupt Dispatcher) при каждой генерации прерывания устройством, и она обязана полностью обслужить это прерывание.
Теперь о callback процедурах сихронизации доступа к объектам. Для начала разберёмся, в чём различия принципов сихронизации доступа к объектам в пользовательском и ядерном режимах. Например, в пользовательском режиме, если какой - либо поток обратился к объекту, уже занятому другим потоком, то он
(первый поток) запросто может быть заблокирован до лучших времён. Как ты сам понимаешь, в режиме ядра такая внеплановая "заморозка" потоков неприемлема, поэтому и применяется другая технология сихронизации. И заключается она в следующем. Когда какой-либо поток обращается к объекту, уже занятому другим потоком, то он оставляет свой запрос в очереди запросов. Если драйвер предварительно зарегистрировал особую callback функцию, то диспетчер ввода - вывода при освобождении
требуемого ресурса, уведомит об этом драйвер, вызвав callback - функцию. Таким образом, обеспечивается гарантия ответа на любой запрос к ресурсу, даже если он
(ответ) будет состоять только в том, чтобы уведомить о задержке в обработке и помещении запроса в очередь. Функции, это реализующие: IoAllocateController
(использующаяся для синхронизации доступа к контроллеру), AdapterControl
(использующаяся для синхронизации доступа к DMA каналам
(чаще всего)) и SynchCritSection (использующаяся для корректного обращения к ресурсам; точнее - эта функция позволяет коду с низким уровнем IRQL сделать работу при уровне DIRQL устройства без опасения возникновения конфликтов с ISR).
Также можно упомянуть ещё таймерные процедуры
(нужные для драйверов, выполняющих точный отсчёт временных интервалов; обычно реализуется с использованием IoTimer
(но не всегда)), процедуру IoCompletion (позволяющую WDM драйверу, работающему внутри многослойной драйверной структуры, получать уведомление о завершении обработки IRP запроса, направленного к драйверу нижнего уровня) и CancelRoutine
(если драйвер зарегистрирует эту callback процедуру при помощи вызова IoSetCancelRoutine, то диспетчер ввода - вывода сможет уведомить его об удалении IRP запросов, находящихся в ожидании обработки, что может понадобиться диспетчеру, если пользовательское приложение, инициировавшее эти IRP запросы, неожиданно завершит свою работу после снятия задачи диспетчером задач
(прошу прощения за необходимую тавтологию)).
Ну вот и всё, мы закончили обзор структуры драйвера и основных его процедур. Примеры их практического применения
(а также некоторых других функций) ты увидишь в третьей, заключительной статье этого цикла, в которой мы напишем свой полноценный Legacy драйвер.
Заключение
Уфф, наконец-то мы покончили со скучной теорией. В этой статье ты узнал про некоторые приёмы программирования в режиме ядра, изучил структуру драйвера и его основные функции. Теперь ты полностью подготовлен
(на сей раз уже окончательно) к написанию своего первого
(или двадцать первого - не знаю) полноценного Legacy драйвера под Windows. Это мы проделаем в заключительной части моего рассказа о программировании драйверов под Windows. А пока что слегка отдохнём. Да не облысеют твои пятки!
