Что такое драйвер

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

Код прикладной программы исполняется в пользовательском режиме работы процессора. В этом случае имеется ряд серьезных ограничений, связанных с доступом к памяти, аппаратным обеспечением и привилегированными инструкциями процессора. Когда возникает необходимость в преодолении этих ограничений, прикладная программа обращается к ядру ОС, код которого исполняется процессором в режиме ядра. Режим ядра лишен всех упомянутых ограничений. Для расширения функциональных возможностей ядра служат драйверы ядра (kernel mode drivers). Как они работают?

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

Под вызовом драйвера здесь подразумевается не обычный вызов функции, а передача так называемого запроса ввода/вывода.

Различают несколько классов драйверов:

Драйвер, получающий запросы ввода/вывода из прикладной программы, называют драйвером высшего уровня. Если такой драйвер не пользуется услугами других драйверов, он называется монолитным.

Драйвер, получающий запросы ввода/вывода от другого драйвера, называют промежуточным, если он пользуется услугами других драйверов, или драйвером низшего уровня, если он не пользуется услугами других драйверов.

Что такое драйвер

Глава 1. Что такое драйвер

С и C++. Интегрированная среда разработки

Необходимо особо отметить, что драйверы предполагается писать на С, а не на C++. Microsoft не поддерживает использование C++ для компонентов ядра. Для этого имеется ряд причин:

отсутствие библиотеки времени исполнения (runtime library), а, следовательно, и определяемых в ней глобальных операторов new и delete4;

отсутствие поддержки исключительных ситуаций C++;

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

В принципе, все эти проблемы разрешимы. Не будем останавливаться на описании конкретных способов. Об этом вы можете узнать в статье «C++ Runtime Support for the NT DDK», а также из анализа заголовочных файлов в продукте DriverWorks (в особенности файла vdw.h).

Как было сказано выше, интегрированная среда Developer Studio не имеет поддержки для создания драйверов. Драйверы компилируются из командной строки с использованием утилиты BUILD, поставляемой в составе DDK.

Реализовать поддержку драйверов из интегрированной среды можно несколькими способами:

реализацией собственного АррWizard (см. АррWizard Programming Reference);

созданием проекта на основе make-файла с вызовом собственного командного файла.

Этот файл должен:

произвести настройку переменных окружения с помощью вызова setenv.bat из DDK;

перейти в директорию с исходным текстом и вызвать утилиту build (см. также статью «Integrating BUILD and Developer Studio» в директории NT Insider).

Реализация собственного Арр Wizard - довольно непростая задача, однако, можно воспользоваться готовым из DriverWorks. Последовательность действий такая: выберите меню Developer Studio File\New... . В появившемся окне на закладке Projects выберите NT/WDM Driver (DriverWorks). В появившемся окне Мастера укажите тип драйвера NT и следуйте инструкциям, внося минимальные изменения. По завершении работы мастера удалите все созданные им срр- и h-файлы, и вставьте собственные с- и h-файлы.

Среда разработки

В этом разделе мы рассмотрим, какое программное обеспечение необходимо для разработки и отладки драйверов, а также его установку и настройку. Необходимое ПО:

1. операционная система Windows NT или Windows 2000, Service Pack и отладочная информация;

2. компилятор;

3. SDK;

4. DDK;

5. средства отладки и вспомогательные средства.

Операционная система имеет два варианта поставки:

Checked build (Debug build);

Free build (Retail build).

Free build - обычная поставка. Включена полная оптимизация, отсутствуют специализированные отладочные возможности.

Checked build - специальная поставка для использования разработчиками драйверов. Оптимизации почти нет, что способствует лучшему пониманию кода при работе под отладчиком. Специализированный отладочный код встроен во многие функции для проверки правильности параметров и перехвата ошибочных ситуаций. Поставляется только в составе подписки MSDN.

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

Необходимо подчеркнуть, что символьная информация различна для checked и free версий системы.

После установки ОС необходимо установить последнюю версию SP. Надо помнить, что SP заменяет почти все системные файлы, и поэтому для них необходима новая символьная информация.

Для checked и free версий системы требуются отдельные версии SP. Кроме того, ОС и SP могут различаться по поддержке криптоалгоритмов (40-128 бит), что может влиять на возможность установки SP.

Компилятор. Хотя принципиально могут использоваться компиляторы различных производителей, структура заголовочных файлов и переменных окружения, поставляемых Microsoft для создания драйверов оптимизирована для использования компилятора Microsoft Visual С. Версия компилятора должна быть не ниже 4.1, однако реально необходимая версия будет зависеть от двух других компонентов - SDK и DDK.

MSDN Library. При установке Developer Studio запрашивается установка MSDN Library. Этот продукт предоставляет информацию о разработке ПО на всех поддерживаемых платформах Microsoft.

SDK. В ранних версиях комплект назывался Win32 SDK, сейчас - Platform SDK. Это необязательный, но желательный для разработки драйверов компонент. Содержит заголовочные файлы, lib-файлы, документацию и примеры программирования на пользовательском уровне с использованием подсистемы Win32.

DDK. Существуют DDK для Windows 95, Windows 98, Windows NT 4.0 и Windows 2000. DDK должен соответствовать платформе, для которой предполагается создание драйвера, что не обязательно для той, на которой производится создание. Мы будем пользоваться DDK для Windows NT 4.0. DDK содержит заголовочные файлы, доку ментацию и примеры написания драйверов, за исключением драйверов файловой системы.

IFS Kit. Пакет для создания драйверов файловой системы. Поставляется как отдельный от подписки MSDN продукт. Существуют версии для Windows 98, Windows NT 4.0 и Windows 2000. Последние версии включают в себя DDK, но с другим набором примеров. Более ранние версии требовали предварительной установки DDK.

Между перечисленным набором компонентов имеется взаимосвязь.

Первым ставится компилятор. Как уже говорилось, хотя существует возможность использования компиляторов других фирм, SDK и DDK предполагают наличие именно Visual С, причем в зависимости от времени выхода SDK и DDK подразумеваются различные версии компилятора (при линковке будут указаны библиотеки различных версий - этим грешит SDK, либо будут некорректно запускаться командные файлы инициализации переменных окружения - этим грешит DDK). Кроме того, ранние версии DDK требовали обязательного наличия установленного SDK. Из возможных проблем стоит указать и то, что при использовании ОС Windows NT Workstation могут не устанавливаться системные переменные окружения.

Расположение командных файлов для установки переменных окружения:

VC98\bin\vcvars32.bat;

Mstools\setenv.bat;

Ddk\bin\setenv.bat.

При наличии версии DDK, требующей наличия SDK, из файла Ddk\bin\setenv.bat должны быть исключены строки проверки наличия SDK и запуска файла setenv.bat, а также прописан вызов vcvars32.bat.

Средства отладки и вспомогательные средства.

Выбор средства отладки - важный момент, который может влиять на набор необходимых аппаратных средств.

Вместе с продуктами Microsoft поставляются четыре отладчика:

1. KD - консольная программа для отладки драйверов режима ядра, находится в директории bin пакета DDK для NT4 и Win2000. (i386kd.exe, ia64kd.exe, alphakd.exe, mipskd.exe).

2. NTSD - консольная программа для отладки программ и драйверов пользовательского режима, находится в директории system32 ОС Windows 2000.

3. CDB - вариант NTSD, содержится в директории bin пакета DDK для Windows 2000.

4. WinDbg - графический отладчик для отладки кода как пользовательского режима, так и режима ядра, содержится в директории bin пакета DDK для Win2000 и Platform SDK.

Из всех перечисленных вариантов упоминания достоин лишь отладчик WinDbg. Он предоставляет удобный пользовательский интерфейс, однако очень неустойчив в работе, плохо документирован и не имеет поддержки от Microsoft. При использовании этого продукта для отладки драйверов необходимы два компьютера - Development Platform и Test Platform. Отладчик доступен для всех поддерживаемых платформ, при этом возможна кроссплатформенная отладка. Поддерживается работа на мультипроцессорных системах.

Лучшим отладчиком для отладки ОС и драйверов многие разработчики с полным основанием считают SoftlCE фирмы NuMega, стабильный при работе, хорошо документированный, с поддержкой от фирмы. Отладка осуществляется на том же компьютере, на котором проводилась разработка, однако возможна и удаленная отладка посредством dos-программы serial.exe. Недостатком можно считать пользовательский интерфейс, однако - это дело привычки. Более серьезными недостатками является ограничение поддержки процессоров только платформой Intel, а также отсутствие поддержки мультипроцессорных систем (однако система все еще активно развивается).

Ниже перечислены средства, которые могут выступать к качестве «наглядного пособия» при написании драйверов (часть этих средств снабжена исходными текстами):

1. Monitor - просмотр трассировочной информации, выводимой драйверами и прикладными программами;

2. Winobj - просмотр пространства имен диспетчера объектов;

3. Handleex - информация о запущенных процессах, всех открытых ими описателях и подгруженных модулях dll;

4. Filemon - просмотр активности файловых систем;

5. Regmon - отслеживание обращений к реестру, в том числе на этапе загрузки системы;

6. Portmon - отслеживание обращений к последовательным и параллельным портам;

7. tdimon - отслеживание запросов TDI;

8. Tokenmon - отслеживание работы системы безопасности.

Типы драйверов и характеристики

В NT существует два типа драйверов: драйверы пользовательского режима и драйверы режима ядра. В дальнейшем, говоря «драйвер», мы будем подразумевать драйвер режима ядра. Такие драйверы являются частью исполнительной системы, а более точно - элементами диспетчера ввода/вывода (архитектура NT и ее компоненты будут обсуждаться ниже). Как следует из названия, при работе драйвера режима ядра процессор находится в режиме ядра (RING 0 - см. любой справочник по защищенному режиму работы процессора).

Драйвер NT располагается в файле с расширением .sys и имеет стандартный РЕ-формат (РЕ - Portable Executable).

Драйверы реализованы как самостоятельные модули с четко определенным интерфейсом взаимодействия с ОС. Все драйверы имеют определенный системой набор стандартных функций драйвера (standard driver routines) и некоторое число внутренних функций, определенных разработчиком.

Драйверы режима ядра можно разбить на три типа:

драйверы высшего уровня (highest level drivers);

драйверы промежуточного уровня (intermediate drivers);

драйверы низшего уровня (lowest level drivers).

Как будет показано ниже, такое разбиение обусловлено многоуровневой моделью драйверов (layered driver model). Для сохранения общности изложения, монолитный драйвер можно включить в эту схему, хотя он не использует многоуровневую архитектуру. В этом случае он будет «гибридом» - драйвером, принадлежащим одновременно к нескольким типам. Например, монолитный драйвер, имеющий интерфейс с приложением и осуществляющий доступ к оборудованию, будет одновременно драйвером высшего и низшего уровня.

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

драйверы файловой системы;

сетевые драйверы.

Отдельно необходимо упомянуть архитектуру WDM - Windows Driver Model. Эта архитектура позволяет создавать драйверы для Windows 98 и Windows 2000, совместимые на уровне двоичного кода.

Характеристики драйверов - это совокупность следующих вопросов:

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

2. Необходимость следовать определенным протоколам взаимодействия с системой, нарушение которых чаще всего ведет к «синему экрану» (Blue Screen Of Death, BSOD).

3. Возможность «наслоения» драйверов поверх друг друга. В Win2000 эта возможность возведена в абсолют, хотя монолитные драйвера все еще поддерживаются.

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

Утилита BUILD

Для построения драйверов и связанных с ними прикладных программ используется утилита BUILD, входящая в состав DDK. Эта утилита позволяет создавать любой тип исполняемого файла, поддерживаемый NT с использованием командной строки. Стандартного (и поддерживаемого Microsoft) способа использования Интегрированной Среды Разработки для написания драйвера не существует. (Варианты, иллюстрирующие то, как это можно сделать, мы рассмотрим в следующем разделе.)

Возможны два варианта построения драйвера:

Checked build - эквивалент Debug build в интегрированной среде;

Free build, также называемый Retail build — эквивалент Release build в интегрированной среде.

Для осуществления конкретного построения необходимо запустить файл setenv.bat с соответствующими параметрами. С целью автоматизации этого процесса при установке DDK создаются ярлыки «Checked Build Environment» и «Free Build Environment». Запуск любого из них вызывает командную оболочку, из которой необходимо вызывать команду build.

Для успешной работы команды build в текущей директории должны находиться два специальных файла: SOURCES и DIRS.

Файл SOURCES является аналогом понятия проект. В нем определяется имя создаваемого модуля, его тип, корневая директория, где будет размещен результат, путь поиска include-файлов, список подключаемых библиотек и список файлов с исходным текстом.

Файл DIRS определяет список поддиректорий, которые должны быть обработаны командой build, прежде чем перейти к текущей директории. Директория, в которой запускается команда build, может содержать либо файл SOURCES, либо файл DIRS, либо оба вместе. Отсутствие файлов является ошибкой.

Директория, в которой содержится только файл DIRS, не будет обработана командой build, но будут обработаны все поддиректории из файла DIRS.

Директория, в которой содержится только файл SOURCES, будет обработана командой build, но ни одна поддиректория обработана не будет.

Директория, в которой содержатся оба файла, будет обработана командой build только после обработки всех поддиректорий из файла DIRS.

Примеры файлов можно посмотреть в DDK, а полное описание утилиты build и структуры файлов - в документации к IPS Kit (В принципе, можно воспользоваться документацией к DDK, однако там описание менее понятно.)

Теперь рассмотрим некоторые отличия checked и free build. Как ясно из названия, это отладочный и окончательный варианты драйвера. Соответственно, они отличаются режимами оптимизации кода. Для режима checked создается отладочная информация в формате dbg, которую можно использовать для отладки в символьном режиме с помощью Softlce. В режиме checked на этапе компиляции определено имя DBG, которое может быть использовано директивами

#if DBG

...

#else

...

fendif

для выполнения действий, специфичных для checked или free версий драйвера. Типичным примером является обрамление таким способом функции DbgPrintO, которая выводит трассировочную информацию. Функция работает и в checked, и в free build, однако с помощью такой проверки ее можно исключить из free build.

Хорошо известная техника Microsoft по написанию кода - использование макроса ASSERTQ. Этот макрос проверяет условие. Если оно ложно, генерируется прерывание. При этом отладчику сообщается имя файла с исходным текстом и номер строки с макросом. Макрос работает только в checked-версии драйвера, установленного на checked-версии ОС. Во всех остальных случаях ничего не происходит.

При создании серьезного продукта цикл разработки драйвера выглядит примерно так:

1. написание кода;

2. проверка и отладка отладочной версии драйвера на отладочной версии ОС;

3. проверка и отладка отладочной версии драйвера на рабочей версии ОС;

4. проверка рабочей версии драйвера на рабочей версии ОС;

5. проверка работы на многопроцессорной системе.

Особо обратите внимание на последний пункт. Нет никакого другого способа убедиться в корректной работе драйвера на многопроцессорной системе, кроме его тестирования на такой системе, даже при условии корректной работы драйвера на однопроцессорной системе.