Понятие ОС. 9 Понятие «драйвер». Обновление драйвера. Функционирование драйв. Понятие драйвер. Обновление драйвера. Функционирование драйвера. Поиск драйверов для оборудования

• Название: Понятие драйвер. Обновление драйвера. Функционирование драйвера. Поиск драйверов для оборудования
• Анкор: Понятие ОС
• Дата: 07.10.2022
• Размер: 39.92 Kb.
• Имя файла: 9 Понятие «драйвер». Обновление драйвера. Функционирование драйв.docx
• Тип: Лекция; #720451

ТЕМА: Понятие «драйвер». Обновление драйвера. Функционирование драйвера. Поиск драйверов для оборудования.

ТИП: лекция

ЦЕЛИ :

Учебная :

• 
  Определить принцип работы драйверов операционных систем ОС;
  
• 
  Изучить алгоритм работы драйвера;
  

Развивая :

• 
  • развивать логическое мышление , внимание , память ;
  
• 
  • развивать кругозор .
  

Воспитательная :

• развивать познавательный интерес к предмету.

Структура занятия

1 . Организационный момент ( 3 мин )

2 . Сообщения темы , цели занятия ( 5 мин )

3 . Актуализация знаний ( 15 мин )

4 . Выдача теоретического материала ( 30 мин )

5 . Проверка полученных знаний ( 10 мин )

6 . Подведение итогов , выставление оценок ( 5 мин )

7 . Выдача домашнего задания ( 2 мин )

Литература.

1. 
   БатаевА.В. Операционные системы и среды : учебник для студ. учреждений сред. проф. образования / А. В. Батаев, Н. Ю. Налютин, С. В. Синицын. - М. : Издательский центр «ДХаде­мия», 2014. - 272 с.
   
2. 
   Иртеrов Д. В. Введение в операционные системы. ­ 2-е изд., перераб. и доп. ­ СПб.: БХВ..Петербурr, 2008. ­ 1040 с.
   
3. 
   Таненбаум Э., Бос Х. Современные операционные системы. 4-е изд. — СПб.: Питер, 2015. — 1120 с.
   

Вопрос актуализации знаний:

План

Ограничения, налагаемые на драйвер 2

Назначение и взаимосвязь основных объектов 3

Объект-драйвер 4

Объект-устройство 4

Объект-файл и файловые описатели (HANDLE) 5

Пакет запроса ввода/вывода (IRP) 6

Точки входа драйвера 7

Контекст исполнения 9

Уровень IRQL 10

Точка входа DriverEntry 11

Определение всех других точек входа драйвера 11

Определение конфигурации аппаратного устройства, все, связанное с его инициализацией 12

Запрос содержимого реестра 12

Создание объекта-устройство и символической связи 12

Ограничения, налагаемые на драйвер

• 
  Драйвер режима ядра не может использовать API пользовательского уровня или стандартные библиотеки времени исполнения языка С. Можно использовать только функции ядра.
  
• 
  Драйвер не может осуществлять операции с числами с плавающей точкой. Попытка сделать это может вызвать аварийную остановку системы. Причина – в основе реализации архитектуры MMX. На вдаваясь в подробности можно сказать, что в этой архитектуре для обозначения регистров MMX использованы те же обозначения, что и для использования регистров FPU. Переключение между использованием регистров MMX/FPU, производимое на пользовательском уровне, невидимо для драйвера.
  
• 
  Драйвер не может манипулировать напрямую физической памятью. Однако, он может получить виртуальный адрес для любого физического адреса и манипулировать им.
  
• 
  Код драйвер не должен долгое время работать на повышенных уровнях IRQL.
  

Другие ограничения можно посмотреть в [Developing Windows NT Device Driver, chapter 5, Driver Limitation]

Назначение и взаимосвязь основных объектов

Рис. 1

Драйвер – это особый тип динамически подключаемой библиотеки (DLL). Фактически, это DLL, удовлетворяющая ряду дополнительных требований и меющая расширение “.sys”.

Как и любая DLL, драйвер имеет свою точку входа – функцию, вызываемую при загрузке исполняемого файла в память. Адрес этой точки входа содержится в служебной информации в самом модуле. При создании модуля в процессе компиляции настройки среды разработки предполагают, что имя соответствующей функции будет DriverEntry, хотя оно может быть заменено на любое другое.

Когда происходит загрузка модуля? Это определяется соответствующими данному драйверу настройками в реестре (ключ Start). Как уже говорилось, этими настройками управляет Service Control Manager (SCM), хотя они могут быть изменены и вручную.

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

Объект-драйвер

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

Примечание.

Microsoft не гарантирует неизменность недокументированных полей любых своих структур в последующих версиях ОС. Однако фактически, некоторые недокументированные в DDK элементы различных системных структур документированы в другом пакете для разработчика – IFS Kit.

Внутри функции DriverEntry происходит инициализация всего, что необходимо для выполнения драйвером его предназначения. В этой функции определяются стандартные и опциональные точки входа драйвера, в особенности – точки входа Dispatch, являющиеся частью структуры DRIVER_OBJECT. Кроме того, обычно именно здесь происходит создание одного или нескольких объектов-устройств.

Объект-устройство

Объект-устройство представляет физическое или логическое устройство, которое должно быть использовано в качестве получателя запросов ввода/вывода. Формат объекта-устройство определяется частично документированной структурой данных DEVICE_OBJECT. Хотя объект-устройство может быть создан в любое время посредством вызова функции IoCreateDevice(), обычно он создается внутри DriverEntry. При этом указывается размер структуры Device Extension (собственно структура как тип определяется разработчиком драйвери). Эта структура используется для хранения данных, специфичных для конкретного объекта-устройство. При создании объекта-устройство также может быть указано его имя, которое будет видимо в директории “\Device” пространства имен диспетчера объектов. Если имя не указано, объект-устройство может быть использован только внутри драйвера и недоступен извне. Если быть более точным, такой объект-устройство можно использовать, если иметь указатель на описывающую его структуру.

Именованный объект-устройство доступен для использования через вызов системного сервиса NtCreateFile().

Имя устройства и символическая связь

Для обращении к именованному объекту-устройство из подсистемы Win32 посредством функции CreateFile() должны быть предприняты дополнительные действия. Функция CreateFile() ищет имя устройства в директории Диспетчера Объектов “\??” (NT 4.0 и W2K) либо “\DosDevices”(NT 3.51). Поэтому в соответствующей директории – для большей совместимости это должна быть “\DosDevices” – должен быть создан объект-символическая связь, указывающий на имя устройства в директории “\Device”. Обычно связь создается в самом драйвере, хотя это можно сделать и из прикладной программы пользовательского режима с помощью Win32-функции DefineDosDevice().

Объект-файл и файловые описатели (HANDLE)

Что происходит при успешном открытии объекта-устройство (неважно, с помощью какой функции: CreateFile() или NtCreateFile())? Для описания состояния работы с каждым объектом, открытым с помощью этих функций, создается объект-файл. Особо необходимо подчеркнуть, что создается не новый экземпляр некоторого объекта некоторого типа, имя которого передается этим функциям, а новый экземпляр объекта-файл. Именно отсюда название функций – CreateFile.

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

Соответственно, каждая операция в/в на прикладном уровне будет производиться с некоторым объектом-файл. Причем конкретный объект будет указан не напрямую, а через так называемый описатель (HANDLE), возвращаемый как результат работы функции CreateFile().

Важно отметить, что каждый процесс имеет свою собственную таблицу описателей, обеспечивая уникальность описателей только в рамках своей таблицы. Это означает, например, что для двух процессов – А и В – описателю со значением 1 будут в общем случае соответствовать 2 различных объекта-файла. Кроме того, ОС поддерживает механизм наследования описателей. В этом случае 2 разных процесса через 2 разных описателя будут разделять один и тот же объект-файл.

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

Пакет запроса ввода/вывода (IRP)

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

Описанная в этом разделе взаимосвязь объектов паказана на рис.1.

Установление и разрушение взаимосвязей между объектами имеет очень важное значение для понимания моментов вызовов и последовательности вызовов Диспетчерских точек входа (Будут рассмотрены на следующей лекции).

Точки входа драйвера

При написании любого драйвера необходимо помнить 4 основных момента:

• 
  Возможные точки входа драйвера
  
• 
  Контекст, в котором могут быть вызваны точки входа драйвера
  
• 
  Последовательность обработки типичных запросов
  
• 
  Уровень IRQL, при котором вызывается точка входа, и, следовательно, ограничения на использование некоторых функций ОС (каждая (!!!) функция ОС может быть вызвана только при определенных уровнях IRQL – см. описание любой функции в DDK, там всегда указаны эти уровни)
  

Архитектура драйвера Windows NT использует модель точек входа, в которой Диспетчер Ввода - вывода вызывает специфическую подпрограмму в драйвере, когда требуется, чтобы драйвер выполнил специфическое действие. В каждую точку входа передается определенный набор параметров для драйвера, чтобы дать возможность ему выполнить требуемую функцию.

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

Далее мы перечислим точки входа либо классы точек входа драйвера:

• 
  DriverEntry. Диспетчер Ввода - вывода вызывает эту функцию драйвера при первоначальной загрузке драйвера. Внутри этой функции драйверы выполняют инициализацию как для себя, так и для любых устройств, которыми они управляют. Эта точка входа требуется для всех NT драйверов.
  

• 
  Диспетчерские (Dispatch) точки входа. Точки входа Dispatch драйвера вызываются Диспетчером Ввода - вывода, чтобы запросить драйвер инициировать некоторую операцию в/в.
  

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

• 
  Fast I/O. Вместо одной точки входа, на самом деле это набор точек входа. Диспетчер Ввода - вывода или Диспетчер Кэша вызывают некоторую функцию быстрого в/в (Fast I/O), для инициирования некоторого действия "Fast I/O". Эти подпрограммы поддерживаются почти исключительно драйверами файловой системы.
  

• 
  Управление очередями запросов IRP (сериализация – процесс выполнения различных транзакций в нужной последовательности). 2 типа: Системная очередь (StartIo) и очереди, управляемые драйвером. Диспетчер Ввода - вывода использует точку входа StartIo только в драйверах, которые используют механизм Системной Очереди (System Queuing). Для таких драйверов, Диспетчер Ввода - вывода вызывает эту точку входа, чтобы начать новый запрос в/в.
  

• 
  Reinitialize. Диспетчер Ввода - вывода вызывает эту точку входа, если она была зарегистрирована, чтобы позволить драйверу выполнить вторичную инициализацию.
  

• 
  Точка входа процедуры обработки прерывания (ISR - Interrupt Service Routine). Эта точка входа присутствует, только если драйвер поддерживает обработку прерывания. Как только драйвер подключен к прерываниям от своего устройства, его ISR будет вызываться всякий раз, когда одно из его устройств запрашивает аппаратное прерывание.
  

• 
  Точки входа вызовов отложенных процедур (DPC – Deferred Procedure Call). 2 типа DPC: DpcForIsr и CustomDpc. Драйвер использует эти точки входа, чтобы завершить работу, которая должна быть сделана в результате появления прерывания или другого специального условия.
  

• 
  SynchCritSection. Диспетчер Ввода - вывода вызывает эту точку входа в ответ на запрос драйвера на захват одной из спин-блокировок его ISR.
  

• 
  AdapterControl. Диспетчер Ввода - вывода вызывает эту точку входа, чтобы указать, что общедоступные DMA-ресурсы драйвера доступны для использования в передаче данных. Только некоторые драйверы устройств DMA реализуют эту точку входа.
  

• 
  Cancel. Драйвер может определять точку входа Cancel для каждого IRP, который он содержит во внутренней очереди. Если Диспетчер Ввода - вывода хочет отменить конкретный IRP, он вызывает подпрограмму Cancel, связанную с этим IRP.
  
• 
  IoCompletion. Эту точку входа для каждого IRP может устанавливать драйвер верхнего уровня при многоуровневой организации. Диспетчер Ввода - вывода вызывает эту подпрограмму после того, как все драйверы нижнего уровня завершили IRP.
  
• 
  IoTimer. Для драйверов, которые инициализировали и запустили поддержку IoTimer, Диспетчер Ввода - вывода вызывает эту точку входа приблизительно каждую секунду.
  
• 
  CustomTimerDpc. Эта точка входа вызывается, когда истекает время для запрошенного драйвером таймера.
  

Контекст исполнения

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

Вначале необходимо определиться с тем, что мы подразумеваем под контекстом исполнения?

Контекст исполнения определяется двумя составляющими:

1. 
   исполняемый в настоящее время поток (контекст планирования потока – thread scheduling context)
   
2. 
   контекст памяти процесса, которому принадлежит поток.
   

Текущий контекст исполнения может принадлежать одному из трех классов:

• 
  контекст процесса “System” (далее - системный контекст)
  
• 
  контекст конкретного потока и процесса
  
• 
  контекст случайного потока и процесса (далее – случайный контекст)
  

Различные точки входа в драйвер могут вызываться в контексте, принадлежащем одному из этих классов.

DriverEntry всегда вызывается в системном контексте.

Диспетчерские функции для драйверов верхнего уровня (т.е. получающих запрос от прикладных программ) вызываются в контексте инициирующего запрос потока.

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

Все точки входа, связанные с сериализацией запросов в/в или с обработкой прерываний и DPC, вызываются в случайном контексте.

Уровень IRQL

DriverEntry всегда вызывается на IRQL=PASSIVE_LEVEL.

Диспетчерские точки входа вызываются на IRQL=PASSIVE_LEVEL или APC_LEVEL.

Вызов отложенных процедур – DISPATCH_LEVEL

Функции обработки прерываний – один из DIRQL.
Практически все последующие разделы этой и следующих лекций будут посвящены описанию различных точек входа драйвера.

Точка входа DriverEntry

Диспетчер в/в вызывает точку входа DriverEntry при загрузке драйвера. В NT может существовать только один экземпляр драйвера, вне зависимости от числа физических устройств, контролируемых им. Таким образом, DriverEntry вызывается только один раз, на уровне IRQL=PASSIVE_LEVEL в системном контексте.

Прототип DriverEntry:

NTSTATUS DriverEntry( IN PDRIVER_OBJECT DriverObject,

IN PUNICODE_STRING RegistryPath);

где DriverObject – указатель на объект-драйвер, соответствующий загружаемому драйверу

RegistryPath – указатель на строку в формате Unicode с именем ключа реестра, соответствующего загружаемому драйверу.

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

В функции DriverEntry обычно происходит:

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

Определение всех других точек входа драйвера

Описывать в этом разделе задание всех возможных точек входа бессмысленно. Эта информация будет описана на протяжении примерно 7 последующих лекций.

Определение конфигурации аппаратного устройства, все, связанное с его инициализацией

В данном курсе делается упор на создание служебных драйверов, не управляющих физическими устройствами. Поэтому довольно обширную тему, связанную с подготовкой драйвера к использованию аппаратного устройства мы пропустим. Интересующихся отсылаю к [Device Driver Development, chapter 13. Driver Entry].

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

Запрос содержимого реестра

В соответствии с принятыми соглашениями, драйвера хранят настроечные параметры в ключе реестра \HKLM\CurrentControlSet\Services\DrvName\Parameters или …\DrvName\DeviceX\Parameters.

Наиболее простой способ запроса содержимого реестра предоставляет функция RtlQueryRegistryValues(). Имя ключа реестра \HKLM\CurrentControlSet\Services\DrvName содержится во втором параметре функции DriverEntry.

Создание объекта-устройство и символической связи

Как уже говорилось, объект-устройство представляет физическое или логическое устройство, которое должно быть использовано в качестве получателя запросов ввода/вывода. Именованный объект-устройство может быть использован либо из прикладного уровня посредством вызова (Nt)CreateFile(), либо из другого драйвера посредством вызова IoGetDeviceObjectPointer().

Создается объект-устройство с помощью вызова функции IoCreateDevice().

NTSTATUS IoCreateDevice( IN PDRIVER_OBJECT DriverObject,

IN ULONG DeviceExtensionSize,

IN PUNICODE_STRING DeviceName,

IN DEVICE_TYPE DeviceType,

IN ULONG DeviceCharacteristics,

IN BOOLEAN Exclusive,

OUT PDEVICE_OBJECT *DeviceObject);

Стоит упомянуть, что при необходимости создания нескольких именованных объектов-устройств одного типа (параметр DeviceType) стандартные драйвера NT пользуются определенным соглашением (которое не является обязательным). А именно: к фиксированному имени прибавляется номер устройства начиная с нуля. Например, COM0, COM1,… Это позволяет открывать устройства, про которые заранее не известно, существуют они или нет. Для получения следующего номера, для которого еще не создано устройство, драйвер может использовать функцию IoGetConfigurationInformation(). Эта функция возвращает указатель на структуру, содержащую число устройств текущего драйвера для каждого обнаруженного типа устройства.

Параметр “тип устройства” (DeviceType) может принимать или одно из предопределенных в ntddk.h значений, начинающихся с FILE_DEVICE_, либо значение в диапазоне 32768…65535, зарезервированном для нестандартных устройств.

Необходимо отметить, что при определении кода запроса в/в к устройству(Device i/o control code, будет рассмотрен на следующей лекции) следует использовать тот же тип устройства.

Параметр “характеристики устройства” (DeviceCharacteristics) является набором флагов и представляет интерес в основном для разработчиков стандартных типов устройств. Среди возможных значений флагов – FILE_REMOVABLE_MEDIA, FILE_READ_ONLY_DEVICE, FILE_REMOTE_DEVICE.

Параметр “эксклюзивность устройства” (Exclusive). Когда этот параметр установлен в TRUE, для устройства может быть создан единственный объект-файл. Как видно из рисунка 1, взаимосвязь различных объектов может быть довольно сложна. При этом довольно часто в драйвере необходимо представлять, от какого файлового объекта поступил запрос. Для упрощения ситуации можно разрешить использование только одного файлового объекта, т.е. в один момент времени устройство будет использоваться только из одного места.

Как уже говорилось, для открытия устройства из подсистемы Win32 для имени устройства в директории \Device в пространстве имен диспетчера объектов должна быть создана символическая связь в директории \?? или \DosDevices. Это можно сделать в драйвере с помощью функции IoCreateSymbolicLink(), либо из прикладной программы с помощью Win32-функции DefineDosDevice().