Драйверы режима ядра: Часть 15 : Жизненный цикл IRP — Архив WASM.RU

В этой и следующей статье мы рассмотрим принципы фильтрации (перехвата) пакетов запроса в/в (IRP). Для чего нужно перехватывать чужие IRP? Применений этому много. Например, захотелось нам посмотреть, к каким файлам обращается та или иная программа. Что мы сделаем в первую очередь? Правильно - запустим FileMon ( sysinternals.com ), который установит драйвер-фильтр на файловую систему. А поскольку обращение к файлам - это фактически формирование соответствующих IRP (быстрый в/в, при котором формирования IRP не происходит, не в счет) и посылка их драйверам файловой системы, то прежде чем добраться до адресата, IRP попадет в фильтр и FileMon зафиксирует это обращение, после чего перешлет его адресату. При этом воздействовать на перехватываемые пакеты FileMon не может. Его задача - только регистрировать факт посылки IRP. Другой пример. Допустим, вам понадобилось скрыть, например, от ваших ближайших родственников или коллег по работе, наличие некоторых файлов фривольного содержания. Недолго думая, вы наберете в google что-то вроде "Hide Files And Folders" и тут же найдете кучку программ, позволяющих скрывать отдельные файлы и каталоги. Это возможно благодаря тому же самому механизму фильтрации IRP. Получая доступ к пакету, драйвер-фильтр имеет возможность модифицировать передаваемые в нём данные, как на пути к файловой системе, так и обратно. Разумеется, фильтровать можно не только IRP передающиеся в файловую систему, но и любые другие. Фильтрация IRP - это общий и универсальный механизм. Антивирусные мониторы, файерволы, на лету компрессоры/декопрессоры крипторы/декрипторы и т.д. и т.п. используют механизм фильтрации IRP. Фильтр, который мы напишем в следующий раз, будет отслеживать IRP, связанные с клавиатурным вводом.

Фильтрация пакетов запроса в/в - достаточно сложная тема. Поэтому, прежде чем перейти к практической реализации потребуется хотя бы минимальная теоретическая подготовка. Как минимум, надо четко представлять себе жизненный цикл IRP от "рождения до смерти". В этой статье мы, в основном, и будем заниматься исследованием этого вопроса. Поскольку драйверы, обслуживающие клавиатуру, в полной мере поддерживают механизм Plug And Play, то придется, в минимальном объеме, осветить и этот вопрос. При этом наш фильтр не будет драйвером Plug And Play. Это будет по-прежнему унаследованный (legacy), в терминологии Microsoft, драйвер, но подключать мы его будем к Plug And Play драйверу.

Ввиду сложности темы, мне вряд ли удастся осветить этот вопрос со всех сторон. Много дополнительной информации можно получить из раздела DDK "Handling IRPs". В Installable File System Kit (IFS KIT), являющийся надмножеством обычного DDK, имеется также раздел "OSR Technical Articles" куда вошли статьи подготовленные командой Open System Resources ( http://www.osr.com/ ). Если в вашем распоряжении только обычный DDK, то большую часть этих статей, если не все, а также много дополнительной информации можно найти в онлайновом журнале "The NT Insider" ( http://www.osronline.com/ ).

Общая классификация драйверов WDM

Все Plug And Play драйверы должны соответствовать модели драйверов Windows (Windows Driver Model, WDM). В соответствии с этой моделью драйверы подразделяются на три типа:

• Драйверы шин (Bus Drivers). Управляют логическими или физическими шинами. Отвечают за распознавание устройств, подключение их к управляемой ими шине и оповещение о них диспетчера PnP.
• Функциональные драйверы (Function Drivers). Управляют конкретным типом устройств. Экспортируют рабочий интерфейс устройства операционной системе.
• Драйверы фильтров (Filter Drivers). Занимая более высокий логический уровень, чем функциональные драйверы, добавляют функциональность или изменяют поведение устройства либо другого драйвера. Этот тип драйверов не обязателен для нормальной работы устройства.

  Драйверы фильтров, в свою очередь, подразделяются на:

  • Драйверы фильтров шин (Bus Filter Drivers).
  • Низкоуровневые драйверы фильтров (Lower-Level Filter Drivers).
  • Высокоуровневые драйверы фильтров (Upper-Level Filter Drivers).

Как вы знаете, каждый драйвер должен создать, как минимум, один объект "устройство", которым он будет управлять. Объекты "устройство" WDM также делит на типы:

• Объект "физическое устройство" (Physical Device Object, PDO) - Создается драйвером шины по заданию диспетчера PnP, когда драйвер шины, перечисляя устройства на своей шине, сообщает о наличии какого-либо устройства. PDO представляет физический интерфейс устройства.
• Объект "функциональное устройство" (Functional Device Object, FDO) - Создается функциональным драйвером, который загружается диспетчером PnP для управления обнаруженным устройством. FDO представляет логический интерфейс устройства.
• Необязательная группа объектов "устройство-фильтр" (Filter Device Object, FiDO). Одна группа таких объектов размещается между PDO и FDO (эти объекты создаются драйверами фильтров шин), вторая - между первой группой FiDO и FDO (эти объекты создаются низкоуровневыми драйверами фильтров), а третья - над FDO (эти объекты создаются высокоуровневыми драйверами фильтров).

Дерево устройств

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

Во время загрузки системы диспетчер PnP начинает перечисление устройств с виртуальной шины под именем Root. В качестве виртуального драйвера, обслуживающего эту шину, выступает сама система. Логически, всё устройства (физические и виртуальные) подключены к этой шине. Виртуальный драйвер корневой шины (и драйверы других шин тоже) извлекает необходимую информацию из реестра. В реестр сведения об оборудовании заносятся ещё на этапе установки операционной системы. Программа установки обнаруживает установленные устройства и, используя информационные файлы (INF Files), заполняет соответствующие разделы реестра. Перечисляя устройства на корневой шине, её виртуальный драйвер обнаруживает другие шины (физические и виртуальные), например, физическую шину PCI. На основе данных реестра диспетчер PnP определяет, установлен ли в системе драйвер, способный управлять обнаруженным устройством. Если такой драйвер установлен, диспетчер PnP указывает диспетчеру ввода-вывода (I/O Manager) загрузить его. Если подходящий драйвер не установлен, диспетчер PnP пытается его установить. При этом если не обнаружится соответствующего информационного файла или других необходимых файлов, диспетчер PnP взаимодействует с пользователем, который должен указать месторасположение необходимых компонентов. Будучи загруженным, драйвер, обслуживающий обнаруженную шину, перечисляет подключенные к ней устройства. При этом он может обнаружить другие дополнительные шины. Если для работы устройства, обнаруженного на шине, необходим драйвер, он загружается. Такой рекурсивный процесс - перечисление устройств, загрузка драйвера, дальнейшее перечисление - продолжается до тех пор, пока не будут обнаружены и сконфигурированы все устройства в системе. Диспетчер PnP способен обнаруживать добавление/удаление нового устройства и во время работы системы. В результате перечисления образуется так называемое дерево устройств (Device Tree), отражающее иерархические взаимосвязи между всеми установленными в системе устройствами.

Дерево устройств можно просмотреть с помощью диспетчера устройств (Device Manager). Как выглядит дерево устройств на моём компьютере (в меню "Вид" я выбрал "Устройства по подключению" и отметил "Показать скрытые устройства".) показано на Рис. 15.1.

Рис. 15-1. Дерево устройств.

На рисунке вы можете обнаружить некоторые, созданные нами ранее виртуальные устройства, например, ProcessMon (Process creation/destruction monitor), подключенные (также виртуально) к корневой шине. В Windows 2000 диспетчер устройств показывает все установленные ранее виртуальные устройства, а в Windows XP (и в Windows 2003 Server, наверное, тоже) только активные в данный момент. Информация о виртуальных устройствах извлекается диспетчером устройств из разделов реестра \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_XXX.

Узлы дерева устройств называются узлами устройств (device nodes или devnodes). Каждый узел обслуживается одним или несколькими драйверами. Каким образом система узнает, какие драйверы, какой узел обслуживают?

Все устройства, обнаруженные в процессе установки системы (а также установленные позже), регистрируются в подразделах реестра \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\<enumerator>\<deviceID>\<instanceID>. Где enumerator - драйвер шины, перечисляющий устройства на шине, deviceID - уникальный идентификатор устройств данного типа, instanceID - уникальный идентификатор экземпляра устройства данного типа (по нему можно различать несколько одинаковых устройств).

В процессе перечисления драйвер шины сообщает диспетчеру PnP идентификаторы обнаруженных устройств: deviceID и instanceID. Используя эту информацию, диспетчер PnP находит в реестре драйверы нужные для узла данного устройства.

Пример подраздела Enum для клавиатуры показан на рис 15-2.

Рис. 15-2. Подраздел реестра ветви Enum для клавиатуры.

Как видно из рисунка, перечислителем является ACPI, идентификатор устройства - PNP0303, а идентификатор экземпляра устройства - 3&13c0b0c5&0. Если заглянуть в %SystemRoot%\inf\keyboard.inf, то можно обнаружить, что информация в реестр попадает именно из этого информационного файла. К вашей машине, разумеется, может быть подключена клавиатура другого типа.

Функциональный драйвер задается параметром Service. В данном случае это i8042prt. Параметр ClassGUID (Globally Unique Identifier of Class) определяет подраздел класса устройства \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class. Этот подраздел содержит сведения о драйвере класса устройства. Драйвер класса определяет общую функциональность для всех устройств данного типа. Он ничего не знает о том, как управлять конкретным устройством, но, используя стандартизованные сервисы, взаимодействует с функциональным драйвером, который, в свою очередь, знает, как управляет конкретным типом устройств. В данном случае драйвером класса является kbdclass. Он исполняет роль своего рода буфера между функциональным драйвером i8042prt и подсистемой Win32 (подробнее в следующей статье). Пример подраздела Class для клавиатуры показан на рис 15-3.

Рис. 15-3. Подраздел реестра ветви Class для клавиатуры.

Содержимое этих двух разделов дает диспетчеру PnP всю информацию необходимую для загрузки драйверов для узла данного устройства. Имена драйверов указывают на подразделы реестра \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<drivername>.

Загрузка драйверов для узла устройства происходит в следующем порядке:

• Низкоуровневые драйверы фильтров, указанные в параметрах LowerFilters ветвей реестра Enum и Class.
• Функциональный драйвер, заданный в параметре Service ветви реестра Enum.
• Высокоуровневые драйверы фильтров, указанные в параметрах UpperFilters ветвей реестра Enum и Class.

Стек объектов "устройство"

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

Загружая каждый PnP драйвер, диспетчер PnP вызывает стандартную процедуру драйвера AddDevice. В параметре PhysicalDeviceObject передается указатель на объект "физическое устройство", созданный драйвером шины. Загруженный драйвер, в свою очередь, создает свой объект "устройство" и подключает его к объекту "физическое устройство", вызовом функции IoAttachDeviceToDeviceStack. В эту функцию он передает два указателя: переданный ему диспетчером Pnp указатель на объект "физическое устройство" и указатель на созданный им объект "устройство". При этом новый объект всегда подключается к самому верхнему объекту в этой цепочке, вне зависимости от того, имеется ли над PDO другие объекты или нет. Указатель на объект "физическое устройство", при подключении нового объекта, используется как указатель на цепочку объектов, к которой происходит подключение, а не указатель на конкретный объект "устройство". Функция IoAttachDeviceToDeviceStack сама находит самый верхний объект.

Получившаяся конструкция состоит, как минимум, из двух объектов: объект "физическое устройство", созданный драйвером шины, и объект "функциональное устройство", созданный функциональным драйвером, и называется стеком объектов "устройство" (device stack) или просто стеком. Т.о. каждый узел в дереве устройств представлен своим стеком.

Учитывая всё вышесказанное, и имея содержимое разделов реестра Enum и Class, мы можем предсказать, из каких объектов будет состоять стек для узла устройства "клавиатура" (объекты перечисляются снизу вверх):

• объект "физическое устройство", созданный драйвером шины ACPI.
• объект "функциональное устройство", созданный функциональным драйвером i8042prt.
• объект "устройство-фильтр", созданный высокоуровневым драйвером фильтра nmfilter (NTICE Support File).
• объект "устройство-фильтр", созданный высокоуровневым драйвером фильтра kbdclass.

Оба объекта "устройство-фильтр" созданы высокоуровневыми драйверами фильтров, а драйверов фильтров шины и низкоуровневых драйверов фильтров в данном случае нет.

Просмотреть стеки устройств можно с помощью программы Devide Tree ( osr.com или osronline.com ). Но я избегаю пользоваться этой утилитой, т.к. её работа на трех моих машинах с разными версиями системы неизбежно приводит к появлению "синего экрана смерти" (по крайней мере, в режиме PnP). Удивительно, что эта утилита входит в DDK. Мы воспользуемся более надежной командой !devstack отладчика Kernel Debugger.

Рис. 15-4. Стеки объектов "устройство" для клавиатуры.

На этой машине активна система Terminal Server и у клавиатуры имеется не один, а два стека. Как видите, наши предположения о составе устройств подтвердились. На вашей машине его состав, естественно, может отличаться. Далее мы будем рассматривать классический состав стека для клавиатуры, а именно: Kbdclass сверху, i8042prt посередине, ACPI внизу.

В общем случае стек объектов "устройство" может выглядеть так (см. классификацию драйверов и объектов в WDM выше):

Рис. 15-5. Стек объектов "устройство" для узла устройства (общая схема).

Поскольку каждым объектом "устройство" в стеке управляет драйвер, то очень часто наряду с понятием "стек устройств" употребляют "стек драйверов". Это не совсем верно, но о чём идет речь, надеюсь, понятно. Далее по ходу статьи я тоже буду иногда говорить "стек устройств", и иногда "стек драйверов".

IRP формируется диспетчером в/в или драйвером не принадлежащим стеку и направляется на вершину стека. Если для обработки запроса драйверу требуется помощь нижестоящего драйвера, он перенаправляет IRP ниже по стеку и т.д. IRP всегда идет по стеку сверху вниз. Решение об окончании обработки IRP может быть принято на любом уровне. Мало того, любой драйвер в стеке может сформировать дополнительные IRP (например, разбить запрос чтения из файла на несколько запросов) и разслать его необходимым драйверам. Любой драйвер может отклонить запрос или может модифицировать передаваемые в нем данные. В общем случае, если драйвер получил IRP, то может делать с ним всё что угодно.

Язык с за три минуты

Мне придется использовать исходные коды некоторых системных функций, т.к. по-настоящему разобраться с обработкой IRP без анализа исходного кода, по-моему, невозможно. Эти фрагменты, конечно, не будут истинным кодом операционной системы и будут урезаны, порой весьма значительно. Также опущена вся обработка ошибок: проверки указателей, входных данных и возвращаемых функциями значений, убраны обработчики SEH. Оставлена только самая суть. Для упрощения анализа кода я буду использовать c-подобный псевдоязык (почти чистый с). Вполне допускаю, что вы можете и не знать этого языка, т.к. мы всё же занимаемся разработкой драйверов на ассемблере. Поэтому тезисно приведу базовые конструкции, без которых не обойтись.

На ассемблере место под инициализированную переменную отводится так:

Код (Text):

1.  
2.  
3.  dw DWORD 0
4.  
5.  

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

Код (Text):

1.  
2.  
3.  DWORD dw = 0;
4.  
5.  

Если надо передать адрес переменной в функцию (используя макрос invoke) мы делаем это так:

Код (Text):

1.  
2.  
3.  invoke SimeFunc, addr dw
4.  
5.  

Программист на с делает это так:

Код (Text):

1.  
2.  
3.  SomeFunc( &dw );
4.  
5.  

Обратная операция - запись в переменную значения по указателю на переменную - в ассемблере это выглядит так (pwd - указатель на переменную размером в двойное слово):

Код (Text):

1.  
2.  
3.  pdw PTR DWORD ?
4.  
5.  mov eax, pdw
6.  mov dword ptr [eax], 0
7.  
8.  

В с это несколько проще:

Код (Text):

1.  
2.  
3.  PDWORD pdw;
4.  
5.  *pdw = 0;
6.  
7.  

Если у нас есть структура FILE_OBJECT, то мы можем записать в её поле DeviceObject указатель на объект "устройство" таким образом:

Код (Text):

1.  
2.  
3.  FileObject     FILE_OBJECT    
4.  pDeviceObject  PDEVICE_OBJECT ?
5.  
6.  mov eax, pDeviceObject
7.  mov FileObject.DeviceObject, eax
8.  
9.  

Программист на с делает это так:

Код (Text):

1.  
2.  
3.  FILE_OBJECT     FileObject;
4.  PDEVICE_OBJECT  pDeviceObject;
5.  
6.  FileObject.DeviceObject = pDeviceObject;
7.  
8.  

Если же, вместо структуры, в нашем распоряжении указатель на неё, то вышеозначенную операцию нам придется делать примерно так:

Код (Text):

1.  
2.  
3.  pFileObject PFILE_OBJECT ?
4.  pDeviceObject  PDEVICE_OBJECT ?
5.  
6.  mov ecx, pFileObject
7.  mov eax, pDeviceObject  
8.  mov (FILE_OBJECT PTR [ecx]).DeviceObject, eax
9.  
10.  

Программисту на с, как всегда, немного проще:

Код (Text):

1.  
2.  
3.  PFILE_OBJECT    pFileObject;
4.  PDEVICE_OBJECT  pDeviceObject;
5.  
6.  pFileObject->DeviceObject = pDeviceObject;
7.  
8.  

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

Код (Text):

1.  
2.  
3.  dw = dw + 1;
4.  
5.  

Для уменьшения числа IRP циркулирующих в системе можно сделать это и так:

Код (Text):

1.  
2.  
3.  dw += 1;
4.  
5.  

Такой же трюк можно проделать и с другими тремя математическими операциями. Логические операции тоже можно записывать в такой форме. Например:

Код (Text):

1.  
2.  
3.  dw |= &lt;some flag&gt;
4.  
5.  

Эквивилентно

Код (Text):

1.  
2.  
3.  or dw, &lt;some flag&gt;
4.  
5.  

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

Код (Text):

1.  
2.  
3.  dw++;
4.  
5.  

Такой же трюк можно проделывать и с операцией вычитания.

В дальнейшие подробности вдаваться не будем, этого минимума должно хватить. Также имейте в виду, что в DDK есть полный исходный код драйверов kbdclass и i8042prt. Правда, в разных DDK он немного отличается. Соответственно, отличаются и эти драйверы в разных версиях системы.

Жизненный цикл IRP

Мы уже много раз получали IRP, но ещё ни разу не создавали его сами. Поскольку мы собираемся рассмотреть весь жизненный цикл пакета запроса в/в, то без его создания нам никак не обойтись. С этого и начнем.

Допустим, у нас есть имя объекта "устройство", скажем, \Device\KeyboardClass0. Судя по названию, этот объект имеет какое-то отношение к обслуживанию физического устройства "клавиатура". Для чего этот объект нужен и какова его роль, мы подробнее поговорим в следующей статье. Пока нас интересует только одно: у нас есть имя устройства и мы хотим послать ему какой-нибудь IRP. Это можно сделать вызовом функции IoCallDriver, прототип которой выглядит так:

Код (Text):

1.  
2.  
3.  NTSTATUS
4.    IoCallDriver(
5.      IN PDEVICE_OBJECT  DeviceObject,
6.      IN OUT PIRP        Irp
7.      );
8.  
9.  

Несмотря на название функции, первым аргументом является указатель на объект "устройство", а не "драйвер", которому адресован IRP. Обрабатывать же IRP будет, естественно, драйвер, это устройство создавший. Второй параметр - указатель на сам пакет запроса в/в.

Код (Text):

1.  
2.  
3.  ;@echo off
4.  ;goto make
5.  
6.  .386
7.  .model flat, stdcall
8.  option casemap:none
9.  
10.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
11.  ;                                  I N C L U D E   F I L E S                                        
12.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
13.  
14.  include \masm32\include\w2k\ntstatus.inc
15.  include \masm32\include\w2k\ntddk.inc
16.  
17.  include \masm32\include\w2k\ntoskrnl.inc
18.  
19.  includelib \masm32\lib\w2k\ntoskrnl.lib
20.  
21.  include \masm32\Macros\Strings.mac
22.  
23.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
24.  ;                                     C O N S T A N T S                                            
25.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
26.  
27.  .const
28.  
29.  CCOUNTED_UNICODE_STRING "\\Device\\KeyboardClass0", g_usTargetDeviceName, 4
30.  
31.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
32.  ;                              D I S C A R D A B L E   C O D E                                      
33.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
34.  
35.  .code INIT
36.  
37.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
38.  ;                                    IrpComplete                                            
39.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
40.  
41.  IrpComplete proc uses esi edi pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP, pContext:PVOID
42.  
43.      mov esi, pIrp
44.      assume esi:ptr _IRP
45.  
46.      mov edi, [esi].UserIosb
47.      assume edi:ptr IO_STATUS_BLOCK
48.  
49.      mov eax, [esi].IoStatus.Status
50.      mov [edi].Status, eax
51.  
52.      mov eax, [esi].IoStatus.Information
53.      mov [edi].Information, eax
54.  
55.      assume edi:nothing
56.      assume edi:nothing
57.  
58.      .if [esi].PendingReturned
59.          invoke KeSetEvent, pContext, 0, FALSE
60.      .endif
61.  
62.      invoke IoFreeIrp, pIrp
63.  
64.      mov eax, STATUS_MORE_PROCESSING_REQUIRED
65.      ret
66.  
67.  IrpComplete endp
68.  
69.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
70.  ;                                     QueryPnpDeviceState                                          
71.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
72.  
73.  QueryPnpDeviceState proc uses esi edi ebx pDeviceObject:PDEVICE_OBJECT
74.  
75.  local status:NTSTATUS
76.  local keEvent:KEVENT
77.  local iosb:IO_STATUS_BLOCK
78.  
79.      mov status, STATUS_NOT_SUPPORTED
80.  
81.      mov esi, pDeviceObject
82.      assume esi:ptr DEVICE_OBJECT
83.  
84.      .if ( esi != NULL  &&  [esi]._Type == IO_TYPE_DEVICE )
85.  
86.          movzx eax, [esi].StackSize
87.          invoke IoAllocateIrp, eax, FALSE
88.  
89.          assume esi:nothing
90.                
91.          .if eax != NULL
92.  
93.              mov edi, eax
94.              assume edi:ptr _IRP
95.  
96.              mov [edi].IoStatus.Status, STATUS_NOT_SUPPORTED
97.              and [edi].IoStatus.Information, 0
98.  
99.              mov iosb.Status, STATUS_NOT_SUPPORTED
100.              and iosb.Information, 0
101.  
102.              lea eax, iosb
103.              mov [edi].UserIosb, eax
104.  
105.              assume edi:nothing
106.  
107.              IoGetNextIrpStackLocation edi
108.              mov ebx, eax
109.              assume ebx:ptr IO_STACK_LOCATION
110.  
111.              mov [ebx].MajorFunction, IRP_MJ_PNP
112.              mov [ebx].MinorFunction, IRP_MN_QUERY_PNP_DEVICE_STATE
113.  
114.              assume ebx:nothing
115.  
116.              invoke KeInitializeEvent, addr keEvent, NotificationEvent, FALSE
117.  
118.              IoSetCompletionRoutine edi, IrpComplete, addr keEvent, TRUE, TRUE, TRUE
119.  
120.              invoke IoCallDriver, esi, edi
121.              mov status, eax
122.  
123.              .if eax == STATUS_PENDING
124.  
125.                  invoke DbgPrint, $CTA0("QueryPnpDeviceState: Request pended. Waiting...\n")
126.    
127.                  invoke KeWaitForSingleObject, addr keEvent, Executive, KernelMode, FALSE, NULL
128.  
129.                  mov eax, iosb.Status
130.                  mov status, eax
131.  
132.              .endif
133.  
134.              .if status == STATUS_SUCCESS
135.  
136.                  invoke DbgPrint, $CTA0("QueryPnpDeviceState: Device State: %08X\n"), iosb.Information
137.  
138.              .endif
139.  
140.          .else
141.              mov status, STATUS_INSUFFICIENT_RESOURCES
142.          .endif
143.  
144.      .endif
145.  
146.      mov eax, status
147.      ret
148.    
149.  QueryPnpDeviceState endp
150.  
151.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
152.  ;                                       DriverEntry                                                
153.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
154.  
155.  DriverEntry proc pDriverObject:PDRIVER_OBJECT, pusRegistryPath:PUNICODE_STRING
156.  
157.  local pTargetDeviceObject:PDEVICE_OBJECT
158.  local pTargetFileObject:PFILE_OBJECT
159.  
160.      invoke IoGetDeviceObjectPointer, addr g_usTargetDeviceName, FILE_READ_DATA, \
161.                                       addr pTargetFileObject, addr pTargetDeviceObject
162.      .if eax == STATUS_SUCCESS
163.  
164.          invoke QueryPnpDeviceState, pTargetDeviceObject
165.        
166.          invoke ObDereferenceObject, pTargetFileObject
167.  
168.      .endif
169.  
170.      mov eax, STATUS_DEVICE_CONFIGURATION_ERROR
171.      ret
172.  
173.  DriverEntry endp
174.  
175.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
176.  ;                                                                                                  
177.  ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
178.  
179.  end DriverEntry
180.  
181.  :make
182.  
183.  set drv=QueryPnpDeviceState
184.  
185.  \masm32\bin\ml /nologo /c /coff %drv%.bat
186.  \masm32\bin\link /nologo /driver /base:0x10000 /align:32 /out:%drv%.sys /subsystem:native /ignore:4078 %drv%.obj
187.  
188.  del %drv%.obj
189.  
190.  echo.
191.  pause
192.  
193.  

Получить указатель на нужное нам устройство по его имени мы можем с помощью IoGetDeviceObjectPointer. В случае успеха, эта функция вернёт даже два указателя: один - собственно указатель на нужное нам устройство в переменной pTargetDeviceObject, а второй - указатель на объект "файл" ассоциированный с этим устройством в переменной pTargetFileObject. Откуда взялся объект "файл"? Заглянем внутрь функции IoGetDeviceObjectPointer, а также двух других, которые она вызывает.

Код (Text):

1.  
2.  
3.  PDEVICE_OBJECT
4.    IoGetAttachedDevice(
5.      IN PDEVICE_OBJECT pDeviceObject
6.      )
7.  {
8.      while pDeviceObject->AttachedDevice
9.          pDeviceObject = pDeviceObject->AttachedDevice
10.  
11.      return pDeviceObject;
12.  }
13.  
14.  
15.  
16.  PDEVICE_OBJECT
17.    IoGetRelatedDeviceObject(
18.      IN PFILE_OBJECT pFileObject
19.      )
20.  {
21.      PDEVICE_OBJECT pDeviceObject
22.  
23.      pDeviceObject = pFileObject->Vpb->DeviceObject
24.      ... or ...
25.      pDeviceObject = pFileObject->DeviceObject->Vpb->DeviceObject
26.      ... or ...
27.      pDeviceObject = pFileObject->DeviceObject
28.  
29.      if pDeviceObject->AttachedDevice != NULL
30.          pDeviceObject = IoGetAttachedDevice( pDeviceObject )
31.  
32.      return pDeviceObject
33.  }
34.  
35.  
36.  
37.  NTSTATUS
38.    IoGetDeviceObjectPointer(
39.      IN PUNICODE_STRING  pusObjectName,
40.      IN ACCESS_MASK      DesiredAccess,
41.      OUT PFILE_OBJECT    *out_pFileObject,
42.      OUT PDEVICE_OBJECT  *out_pDeviceObject
43.      )
44.  {
45.      PFILE_OBJECT        pFileObject
46.      OBJECT_ATTRIBUTES   oa
47.      HANDLE              hFile
48.  
49.      InitializeObjectAttributes( &oa, pusObjectName, ... )
50.  
51.      ZwOpenFile( &hFile, DesiredAccess, &oa, ... )
52.  
53.      ObReferenceObjectByHandle( hFile, 0, IoFileObjectType, KernelMode, &pFileObject, NULL )
54.  
55.      *out_pFileObject   = pFileObject
56.      *out_pDeviceObject = IoGetRelatedDeviceObject( pFileObject )
57.  
58.      ZwClose( hFile )
59.  
60.      return STATUS_XXX
61.  }
62.  
63.  

Первым делом, функция IoGetDeviceObjectPointer получает описатель объекта "файл" (представлен структурой FILE_OBJECT).

Вспомните, как в программе управления драйвером мы получаем описатель для взаимодействия с его устройством. Мы вызываем функцию CreateFile, которая создает объект "файл", представляющий не собственно файл на диске, а виртуальное устройство (структура DEVICE_OBJECT), созданное драйвером. Т.е. на самом деле, описатель файла используется для ввода-вывода в устройство. Такая схема нужна, во-первых, для разграничения прав доступа, т.к. в структуре DEVICE_OBJECT нет, например, полей WriteAccess и SharedRead, а в FILE_OBJECT такие поля есть, во-вторых, в объекте "файл" можно хранить некоторые другие атрибуты операции ввода-вывода. Адрес истинного получателя пакета запроса в/в, в нашем случае, находится в поле FILE_OBJECT.DeviceObject. Итак, вызов ZwOpenFile, так же как и CreateFile, приводит к созданию объекта "файл", а значит формированию IRP типа IRP_MJ_CREATE и посылке его целевому устройству (в нашем случае устройству \Device\KeyboardClass0). Этот пакет, как вы понимаете, попадает в драйвер обслуживающий это устройство (устройство \Device\KeyboardClass0 обслуживает драйвер kbdclass). Т.е. решение об удовлетворении запроса - вызове IoCompleteRequest со статусом STATUS_SUCCESS - принимает обслуживающий драйвер.

Вот фрагмент функции KeyboardClassCreate драйвера kbdclass:

Код (Text):

1.  
2.  
3.     PIO_STACK_LOCATION   pStack;
4.  
5.     pStack = IoGetCurrentIrpStackLocation( pIrp )
6.  
7.     if  pIrp->RequestorMode == UserMode
8.             &&
9.         pStack->Parameters.Create.SecurityContext->DesiredAccess & FILE_READ_DATA  {
10.  
11.         status = STATUS_ACCESS_DENIED
12.         goto KeyboardClassCreateEnd
13.     }
14.  
15.  

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

Кстати, раз уж мы так подробно собрались во всем разбираться, посмотрим на внутренности макроса IoGetCurrentIrpStackLocation, который мы сами уже много раз использовали (полная версия в ntddk.inc).

Код (Text):

1.  
2.  
3.  IoGetCurrentIrpStackLocation MACRO pIrp:REQ
4.      mov eax, pIrp
5.      mov eax, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
6.  ENDM
7.  
8.  

Марос IoGetCurrentIrpStackLocation просто извлекает указатель на текущий блок стека из поля CurrentStackLocation.

Получив описатель объекта "файл", функция IoGetDeviceObjectPointer дополнительно увеличивает счетчик ссылок в объекте "файл", вызовом ObReferenceObjectByHandle. Затем IoGetDeviceObjectPointer пытается получить указатель на целевое устройство, сопоставленное с объектом "файл", вызывая IoGetRelatedDeviceObject. В зависимости от принадлежности объекта "файл" тому или иному типу устройств, IoGetRelatedDeviceObject может извлечь необходимый указатель из разных мест (в нашем случае из поля pFileObject->DeviceObject). Далее, обратите на это особое внимание, если к целевому устройству прикреплено ещё одно устройство (об этом говорит ненулевое значение в поле pDeviceObject->AttachedDevice), функция IoGetAttachedDevice "поднимается" по стеку устройств до самого верха и возвращает указатель на устройство, находящееся на вершине стека. Если же прикрепленных устройств нет, то возвращается указатель на само целевое устройство, т.е. то, имя которого было передано в IoGetDeviceObjectPointer. Запомните: Функция IoGetAttachedDevice всегда возвращает указатель на объект "устройство", находящийся на вершине стека.

После получения указателя IoGetDeviceObjectPointer закрывает описатель объекта "файл" и в этот момент счетчик описателей становится равным нулю, что приводит к формированию и посылке драйверу kbdclass IRP типа IRP_MJ_CLEANUP. Т.о. функция IoGetDeviceObjectPointer вернет указатели на два объекта: "файл" и "устройство". Причем в объекте "устройство" значение счетчиков указателей и описателей не меняется, а в объекте "файл" равно 1 и 0, соответственно. Единичное значение счетчика указателей достигается благодаря дополнительному вызову ObReferenceObjectByHandle. До тех пор, пока существует объект "файл", объект "устройство", с которым он связан, не будет удален и соответственно драйвер, управляющий устройством, также не может быть выгружен, т.к. в управляемом им объекте "устройство", будет установлен соответствующий флаг и при попытке выгрузить такой драйвер он отмечается как ожидающий выгрузки, а процедура DriverUnload просто не будет вызвана. Только после того, как будут удалены все управляемые драйвером устройства, драйвер сможет отработать DriverUnload.

Т.о. в случае с IoGetDeviceObjectPointer схема точно такая же, какой пользуется режим пользователя, получая описатель объекта "файл" и таким образом блокируя связанный с ним объект. При этом сам объект "файл" относится к любому источнику или приемнику ввода-вывода (собственно файлу или каталогу, именованному каналу, почтовому ящику и др.), который рассматривается как файл. При таком механизме все считываемые или записываемые данные представляются простыми потоками байтов, направляемыми в виртуальные файлы. По окончании работы, программа режима пользователя закрывает описатель файла, а мы должны будем удалить ссылку, вызовом ObDereferenceObject. При этом счетчик указателей в объекте "файл" обнулится, и это приведет к формированию и посылке драйверу kbdclass IRP типа IRP_MJ_CLOSE. Только после этого объект "файл" будет удален.

Вернемся к исходному коду нашего драйвера.

Код (Text):

1.  
2.  
3.          invoke QueryPnpDeviceState, pTargetDeviceObject
4.  
5.  

Теперь у нас есть адресат для посылки IRP. Осталось только сформировать сам пакет.

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

Код (Text):

1.  
2.  
3.      mov esi, pDeviceObject
4.      assume esi:ptr DEVICE_OBJECT
5.    
6.      .if ( esi != NULL  &&  [esi]._Type == IO_TYPE_DEVICE )
7.  
8.          movzx eax, [esi].StackSize
9.          invoke IoAllocateIrp, eax, FALSE
10.  
11.  

Создать IRP можно одной из четырех функций: IoBuildSynchronousFsdRequest, IoBuildDeviceIoControlRequest, IoBuildAsynchronousFsdRequest и IoAllocateIrp. Если быть совсем точным, то можно сделать IRP вообще вручную, выделив память из пула или ассоциативного списка, но тогда все его поля придется заполнять самим. Мы воспользуемся самой универсальной из четырех вышеперечисленных функций - IoAllocateIrp. В отличие от трех остальных, с её помощью можно создавать IRP любого типа.

По соображениям лучшей производительности, память под IRP выделяется в одном из двух ассоциативных списков, индивидуальных для каждого процессора (структуры управляющие списками хранятся в специфичной для каждого процессора структуре KPRCB). Если нужен IRP с одним блоком стека, то используется ассоциативный список малых IRP. Если IRP должен содержать более одного блока стека - используется ассоциативный список больших IRP. Такие IRP содержат 8 блоков стека (эта цифра хранится в переменной ядра IopLargeIrpStackLocations). В Windows NT4 эта цифра равнялась 4, но с приходом PnP глубина стеков увеличилась. Если же IRP требует более 8 блоков стека или ассоциативный список пуст, то диспетчеру в/в ничего другого не остается, как выделить память под IRP из неподкачиваемого пула. Перед тем как вернуть управление, IoAllocateIrp обнуляет весь IRP и инициализирует некоторые его поля.

Код (Text):

1.  
2.  
3.     Irp.Type                              = IO_TYPE_IRP
4.     Irp.Size                              = sizeof(IRP) + StackSize * sizeof(IO_STACK_LOCATION)
5.     Irp.AllocationFlags                   = <some flags>
6.     Irp.StackCount                        = StackSize
7.     Irp.CurrentLocation                   = StackSize + 1
8.     Irp.Tail.Overlay.CurrentStackLocation = &Irp + sizeof(IRP) + StackSize * sizeof(IO_STACK_LOCATION)
9.  
10.  

Самые важные для нас на данный момент поля это:

• Irp.StackCount - максимально необходимое количество блоков стека в IRP. Это поле будет равно значению первого параметра переданного в IoAllocateIrp. Мы извлекаем его из объекта "устройство", которому собираемся отправить IRP. Каждый объект "устройство" знает, сколько под ним объектов и, соответственно, сколько нужно блоков стека.
• Irp.CurrentLocation - порядковый номер текущего блока стека (отсчет идет в обратном порядке). Каждый раз при передаче IRP нижестоящему драйверу функция IoCallDriver уменьшает значение этого поля на единицу. Изначально же, как видите, оно на один больше чем действительно необходимо.
• Irp.Tail.Overlay.CurrentStackLocation - указатель на текущий блок стека. Каждый раз при передаче IRP нижестоящему драйверу функция IoCallDriver уменьшает его значение на размер структуры IO_STACK_LOCATION. Изначально оно указывает на недействительный блок стека, т.е. на область памяти сразу за концом IRP. Строго говоря, это не всегда так. Например, если IRP выделен из ассоциативного списка больших IRP, то у него 8 блоков стека, а мы, допустим, заказали 5. Тогда CurrentStackLocation будет указывать на один из лишних блоков стека. Если же мы просили IRP с одним блоком или он выделен из пула, то CurrentStackLocation указывает на "чужую" память.

По возвращении из IoAllocateIrp наш IRP выглядит так (я использовал команду irp отладчика SoftICE с ключом -f):

Код (Text):

1.  
2.  
3.  :irp -f 83887008
4.  MdlAddress *         : 00000000
5.  Flags                : 00000000
6.  AssociatedIrp        : 00000000
7.  &ThreadListEntry     : 83887018
8.  IoStatus.Status      : 00000000
9.  IoStatus.Information : 00000000
10.  RequestorMode        : 00
11.  PendingReturned      : False
12.  StackCount           : 05
13.  CurrentLocation      : <b>06</b>
14.  Cancel               : False
15.  CancelIrql           : 00
16.  ApcEnvironment       : 00
17.  UserIosb *           : 00000000
18.  UserEvent *          : 00000000
19.  Overlay              : 00000000 00000000
20.  CancelRoutine *      : 00000000
21.  UserBuffer *         : 00000000
22.  Tail.Overlay
23.         &DeviceQueueEntry : 83887048
24.         Thread *          : 00000000
25.         AuxiliaryBuffer * : 00000000
26.         &ListEntry        : 83887060
27.         CurrentStackLoc * : <b>8388712C</b>
28.         OrigFileObject *  : 00000000
29.  Tail.Apc *           : 83887048
30.  Tail.ComplKey        : 00000000
31.  
32.  StackLocation 1 at 83887078:
33.  <заполнен нулями>
34.  
35.  StackLocation 2 at 8388709C:
36.  <заполнен нулями>
37.  
38.  StackLocation 3 at 838870C0:
39.  <заполнен нулями>
40.  
41.  StackLocation 4 at 838870E4:
42.  <заполнен нулями>
43.  
44.  StackLocation 5 at 83887108:
45.  <заполнен нулями>
46.  
47.  CurrentStackLocation at <b>8388712C</b>:
48.  <заполнен нулями>                      <- недействительный блок стека
49.  
50.  

IoAllocateIrp делает только заготовку будущего IRP. Кое-какие поля требуется заполнить вручную.

Код (Text):

1.  
2.  
3.              mov edi, eax
4.              assume edi:ptr _IRP
5.  
6.              mov [edi].IoStatus.Status, STATUS_NOT_SUPPORTED
7.              and [edi].IoStatus.Information, 0
8.  
9.              mov iosb.Status, STATUS_NOT_SUPPORTED
10.              and iosb.Information, 0
11.  
12.              lea eax, iosb
13.              mov [edi].UserIosb, eax
14.  
15.              assume edi:nothing
16.  
17.  

Для формирования IRP разных типов может потребоваться заполнение разных полей. Я заполнил только самые необходимые для нас и вам не следует принимать это за образец. Подробности можно посмотреть в DDK.

После заполнения тела IRP мы должны сформировать блок стека для драйвера, которому мы адресуем запрос. Если использовать нумерацию блоков стека как её использует SoftIce, то мы должны заполнить блок стека за номером 5. Как вы помните, сейчас поле CurrentStackLocation указывает на недействительный блок стека. Для получения указателя на следующий блок стека, принадлежащий драйверу которому мы адресуем запрос, используется макрос IoGetNextIrpStackLocation:

Код (Text):

1.  
2.  
3.  IoGetNextIrpStackLocation MACRO pIrp:REQ
4.      mov eax, pIrp
5.      mov eax, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
6.      sub eax, sizeof IO_STACK_LOCATION
7.  ENDM
8.  
9.  

Пусть вас не смущает слово next в имени макроса. Мы ведь имеем дело со стеком. "Следующий драйвер" означает нижестоящий драйвер, а "следующий блок стека" - блок стека с адресом на sizeof(IO_STACK_LOCATION) меньше чем текущий блок стека. Соответственно "предыдущий драйвер" означает вышестоящий драйвер, а "предыдущий блок стека" - блок стека с адресом на sizeof(IO_STACK_LOCATION) больше чем текущий блок стека. Макрос IoGetNextIrpStackLocation берет значение из поля CurrentStackLocation и уменьшает его на размер структуры IO_STACK_LOCATION. Таким образом, мы движемся в сторону меньших адресов по направлению к телу IRP.

Код (Text):

1.  
2.  
3.              IoGetNextIrpStackLocation edi
4.              mov ebx, eax
5.              assume ebx:ptr IO_STACK_LOCATION
6.  
7.              mov [ebx].MajorFunction, IRP_MJ_PNP
8.              mov [ebx].MinorFunction, IRP_MN_QUERY_PNP_DEVICE_STATE
9.  
10.  

Мы посылаем запрос типа IRP_MJ_PNP, а дополнительный код IRP_MN_QUERY_PNP_DEVICE_STATE определяет какую именно информацию о PnP характеристиках устройства мы хотим получить.

Код (Text):

1.  
2.  
3.               invoke KeInitializeEvent, addr keEvent, NotificationEvent, FALSE
4.  
5.  

Инициализируем объект "событие". На этом объекте мы будем ждать момента завершения IRP. Тип события может быть и SyncronizationEvent, т.к. всё равно кроме нас, его никто ждать не будет. В исходных кодах драйверов можно встретить оба варианта.

Буквально через одну строку мы собираемся послать IRP драйверу kbdclass. Если мы не предпримем специальных мер, то никогда уже не сможем увидеть наш IRP. Как это не покажется парадоксальным, с первого взгляда, но после вызова IoCallDriver обращаться к IRP нельзя. К концу статьи, надеюсь, будет ясно почему. Единственная возможность вновь получить контроль над IRP - это установить специальную процедуру - процедуру завершения (completion routine). Процедура завершения будет вызвана, в тот момент, когда какой-либо драйвер ниже по стеку завершит IRP вызовом IoCompleteRequest. Одной из задачь функции IoCompleteRequest как раз и является задача вызова всех процедур завершения. Нашу процедуру завершения я назвал IrpComplete, а установить её можно с помощью макроса IoSetCompletionRoutine (полный вариант в ntddk.inc):

Код (Text):

1.  
2.  
3.  IoSetCompletionRoutine MACRO pIrp:REQ, Routine:REQ, CompletionContext:REQ, Success:REQ, Error:REQ, Cancel:REQ
4.  
5.      mov eax, pIrp
6.  
7.      mov eax, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
8.      sub eax, sizeof IO_STACK_LOCATION
9.  
10.      assume eax:ptr IO_STACK_LOCATION
11.  
12.      push Routine
13.      pop [eax].CompletionRoutine
14.  
15.      push CompletionContext
16.      pop [eax].Context
17.  
18.      and byte ptr [eax].Control, 0
19.  
20.      IF Success NE 0
21.          or byte ptr [eax].Control, SL_INVOKE_ON_SUCCESS
22.      ENDIF
23.  
24.      IF Error NE 0
25.          or byte ptr [eax].Control, SL_INVOKE_ON_ERROR
26.      ENDIF
27.  
28.      IF Cancel NE 0
29.          or byte ptr [eax].Control, SL_INVOKE_ON_CANCEL
30.      ENDIF
31.  
32.      assume eax:nothing
33.  
34.  ENDM
35.  
36.  

Первый параметр - указатель на IRP, при завершении которого должна быть вызвана процедура, указатель на которую передается во втором параметре. Третий параметр - указатель на любые данные. Этот указатель будет передан в процедуру завершения, и в нем мы укажем адрес нашего объекта "событие", которое процедура завершения, при необходимости, должна будет перевести в сигнальное состояние. Три последних параметра определяют, в каком случае будет вызвана процедура. Нам нужно, чтобы она была вызвана в любом случае: при завершении IRP с кодом успеха, при завершении IRP с кодом ошибки, при отмене IRP. Т.е. как бы ни завершился IRP, мы всё равно его перехватим на обратном пути. Обратите внимание, что макрос IoSetCompletionRoutine использует следующий блок стека, т.е. предназначенный для нижестоящего драйвера. Т.е. адрес процедуры завершения и её параметр помещаются не в блок стека драйвера, которому он принадлежит, а в блок стека нижестоящего драйвера. Почему мы лезем в чужой блок стека со своей процедурой завершения? Дело в том, что, во-первых, у нас нет своего блока стека, точнее он нам не нужен. Мы же сами формируем IRP и прекрасно знаем, что в нем содержится. С другой стороны, драйверу, стоящему ниже в стеке, который будет завершать IRP, не нужна процедура завершения. Он же сам его завершает и прекрасно знает как.

И ещё один очень важный момент, касающийся процедур завершения. В общем случае обработка ввода/вывода с физического устройства проходит по следующей схеме. Драйвер инициирует операцию в/в. Когда устройство завершает операцию, то генерирует прерывание, которое обрабатывается процедурой обработки прерывания (Interrupt Service Routine, ISR), зарегистрированной драйвером. Причем обработка будет происходить в контексте того потока, который был текущим на момент прерывания, а это случайный поток. Т.к. ISR работает на повышенном IRQL (больше DISPATCH_LEVEL), работа всех остальных потоков на данном процессоре блокируется. Мало того, блокируются (маскируются) все прерывания с таким же или более низким уровнем. Для того чтобы обработать возможные прерывания от менее приоритетных устройств, необходимо как можно быстрее понизить IRQL. Для этого ISR делает только то, что необходимо сделать немедленно и ставит в очередь так называемый вызов отложенной процедуры (Deferred Procedure Call, DPC). DPC работает при IRQL = DISPATCH_LEVEL. Когда IRQL понижается до DISPATCH_LEVEL, система вызывает отложенную процедуру и она делает дополнительные операции по завершению IRP. В самой последней фазе отложенная процедура вызывает IoCompleteRequest, которая, как я сказал выше, вызывает все процедуры завершения. Поэтому процедура завершения может быть вызвана в контексте случайного потока и при IRQL меньше или равном DISPATCH_LEVEL.

Раз процедура завершения может быть вызвана на повышенном IRQL, то очевидно, что и она сама и все данные, к которым она обращается должны находиться в неподкачиваемой памяти. Наша процедура завершения обращается к двум структурам: IO_STATUS_BLOCK и KEVENT (сам IRP не в счет, т.к. он всегда выделяется из неподкачиваемой памяти), которые располагаются в стеке потока, выполняющего процедуру QueryPnpDeviceState. Если этот поток будет ждать, то его стек может быть выгружен в файл подкачки (то, что, в данном случае, это системный поток не в счет). Чтобы запретить системе это делать, необходимо указывать KernelMode в параметре WaitMode функций ожидания. Я уже как-то раз говорил об этом, но, на всякий случай, повторяю.

Код (Text):

1.  
2.  
3.              IoSetCompletionRoutine edi, IrpComplete, addr keEvent, TRUE, TRUE, TRUE
4.  
5.              invoke IoCallDriver, esi, edi
6.  
7.  

Ну что же. Теперь у нас есть всё необходимое: адресат, сформированный IRP и процедура завершения, готовая перехватить его на обратном пути. Вызовом функции IoCallDriver, посылаем IRP драйверу, обслуживающему объект "устройство", указатель на который содержится в первом параметре.

Реализация функции IoCallDriver на удивление проста:

Код (Text):

1.  
2.  
3.  NTSTATUS
4.  IoCallDriver(
5.      IN PDEVICE_OBJECT  pDeviceObject,
6.      IN OUT PIRP        pIrp
7.      )
8.  {
9.  
10.      NTSTATUS             status
11.      PIO_STACK_LOCATION   pStack
12.      PDRIVER_OBJECT       pDriverObject
13.  
14.      Irp->CurrentLocation--
15.  
16.      if  pIrp->CurrentLocation &lt;= 0  {
17.  
18.          KeBugCheckEx( NO_MORE_IRP_STACK_LOCATIONS, pIrp, ... )
19.      }
20.  
21.      pIrp->Tail.Overlay.CurrentStackLocation -= sizeof(IO_STACK_LOCATION)
22.  
23.      pStack = pIrp->Tail.Overlay.CurrentStackLocation
24.  
25.      pStack->DeviceObject = pDeviceObject
26.  
27.      pDriverObject = pDeviceObject->DriverObject
28.  
29.      status = pDriverObject->MajorFunction[pStack->MajorFunction]( pDeviceObject, pIrp )
30.  
31.      return status
32.  }
33.  
34.  

Сначала IoCallDriver уменьшает значение CurrentLocation на единицу и если оно вдруг стало равно нулю или ещё меньше, то система показывает "голубой экран смерти", т.к. нулевое значение в поле CurrentLocation говорит о том, что мы исчерпали все блоки стека и если IoCallDriver пойдет дальше, то просто будет "затирать" тело IRP, что рано или поздно всё равно приведет к краху. Затем значение в CurrentStackLocation уменьшается на размер структуры IO_STACK_LOCATION. Вот теперь оба поля: CurrentLocation и CurrentStackLocation соответствуют заполненному нами блоку стека. CurrentLocation равно 5, а CurrentStackLocation - 83887108. Сейчас наш IRP выглядит так:

Код (Text):

1.  
2.  
3.  :irp -f 83887008
4.  MdlAddress *         : 00000000
5.  Flags                : 00000000
6.  AssociatedIrp        : 00000000
7.  &ThreadListEntry     : 83887018
8.  IoStatus.Status      : C00000BB
9.  IoStatus.Information : 00000000
10.  RequestorMode        : 00
11.  PendingReturned      : False
12.  StackCount           : 05
13.  CurrentLocation      : <b>05</b>
14.  Cancel               : False
15.  CancelIrql           : 00
16.  ApcEnvironment       : 00
17.  UserIosb *           : BE0A4C78
18.  UserEvent *          : 00000000
19.  Overlay              : 00000000 00000000
20.  CancelRoutine *      : 00000000
21.  UserBuffer *         : 00000000
22.  Tail.Overlay
23.         &DeviceQueueEntry : 83887048
24.         Thread *          : 00000000
25.         AuxiliaryBuffer * : 00000000
26.         &ListEntry        : 83887060
27.         CurrentStackLoc * : <b>83887108</b>
28.         OrigFileObject *  : 00000000
29.  Tail.Apc *           : 83887048
30.  Tail.ComplKey        : 00000000
31.  
32.  StackLocation 1 at 83887078:
33.  <заполнен нулями>
34.  
35.  StackLocation 2 at 8388709C:
36.  <заполнен нулями>
37.  
38.  StackLocation 3 at 838870C0:
39.  <заполнен нулями>
40.  
41.  StackLocation 4 at 838870E4:
42.  <заполнен нулями>
43.  
44.  CurrentStackLocation at <b>83887108</b>:
45.  MajorFunction     : 1B IRP_MJ_PNP
46.  MinorFunction     : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
47.  Control           : E0
48.  Flags             : 00
49.  Others            : 00000000 00000000 00000000 00000000
50.  DeviceObject *    : 81852AB0
51.  FileObject *      : 00000000
52.  CompletionRout *  : ED5E14C0
53.  Context *         : BE0A4C68
54.  
55.  

Далее IoCallDriver помещает в поле DeviceObject текущего блока стека указатель на вызываемый объект "устройство". Этот указатель может потребоваться процедуре завершения. Затем из объекта "устройство" извлекается указатель на обслуживающий его драйвер и вызывается одна из процедур диспетчеризации драйвера. Т.к. в pStack->MajorFunction находится IRP_MJ_PNP, IoCallDriver берет из соответствующего элемента массива MajorFunction указатель на процедуру и передает ей адреса объекта "устройство" и IRP (вспомните любую функцию диспетчеризации, коих мы написали уже не мало). Если драйвер не занёс в соответствующее поле массива MajorFunction указатель на свою процедуру обработки данного типа IRP, то по умолчанию там находится указатель на системную функцию IopInvalidDeviceRequest, которая просто возвращает STATUS_INVALID_DEVICE_REQUEST и на этом обработка IRP будет завершена, не начавшись. Если же нужная процедура у драйвера имеется, а kbdclass имеет процедуру для обработки запросов IRP_MJ_PNP, то мы в нее и попадем, а IoCallDriver вернет то, что вернет эта процедура.

Теперь, прежде чем мы погрузимся в kbdclass, немного "уйдем в сторону" и представим, что IRP, только что сформированный нами, не IRP типа IRP_MJ_PNP, а гипотетический IRP_MJ_UNKNOWN, и посылаем мы его абстрактному драйверу unknown, процедура диспетчеризации которого выглядит приблизительно так:

Код (Text):

1.  
2.  
3.  .data?
4.  
5.  g_IrpQueue          LIST_ENTRY  
6.  g_fCompleteLater    BOOL        ?
7.  
8.  .code
9.  
10.  DispatchUnknown proc uses esi pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP
11.  
12.  local status:NTSTATUS              
13.  
14.      mov esi, pIrp
15.      assume esi:ptr _IRP
16.  
17.      .if g_fCompleteLater
18.  
19.          IoMarkIrpPending esi
20.  
21.          &lt;LockQueue&gt;
22.  
23.          lea ecx, [esi].Tail.Overlay.ListEntry
24.          InsertTailList addr g_IrpQueue, ecx
25.  
26.          &lt;UnlockQueue&gt;
27.  
28.          mov status, STATUS_PENDING
29.  
30.      .else
31.  
32.          mov status, STATUS_SUCCESS
33.  
34.          mov [esi].IoStatus.Status, STATUS_SUCCESS
35.          mov [esi].IoStatus.Information, SOME_INFORMATION
36.    
37.          fastcall IofCompleteRequest, esi, IO_NO_INCREMENT
38.  
39.      .endif
40.    
41.      assume esi:nothing
42.  
43.      mov eax, status
44.      ret
45.  
46.  DispatchUnknown endp
47.  
48.  

Драйвер unknown либо сразу завершает IRP, либо ставит его в очередь, для того чтобы завершить позже. Сначала рассмотрим первый случай.

Прежде чем добавить IRP в очередь, драйвер должен отметить его как ожидающий завершения (pending). Это можно сделать с помощью макроса IoMarkIrpPending, который выглядит так:

Код (Text):

1.  
2.  
3.  IoMarkIrpPending MACRO pIrp:REQ
4.      mov eax, pIrp
5.      mov eax, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
6.      or (IO_STACK_LOCATION PTR [eax]).Control, SL_PENDING_RETURNED
7.  ENDM
8.  
9.  

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

Дальше драйвер помещает IRP в очередь и возвращает код STATUS_PENDING, говорящий вышестоящему драйверу о том, что завершение IRP отложено на неопределенное время. В нашем случае, вышестоящий драйвер - наш драйвер и ему необходимы результаты завершения IRP. Поэтому будем ждать, на созданном нами объекте "событие".

Существует несколько механизмов, которыми драйверы могут пользоваться для постановки IRP в очередь, но в итоге все сводится к добавлению IRP в двусвязный список. В самом простом случае можно использовать поле IRP.Tail.Overlay.ListEntry. Для того чтобы гарантировать себе монопольный доступ к очереди драйверы используют блокировку. Как работает очередь и блокировка, сейчас не важно.

По прошествии некоторого времени драйвер решает удалить IRP из очереди и завершить его.

Код (Text):

1.  
2.  
3.      &lt;LockQueue&gt;
4.  
5.      RemoveHeadList addr g_IrpQueue
6.      sub eax, _IRP.Tail.Overlay.ListEntry
7.      mov esi, eax           ; esi -> _IRP
8.  
9.      &lt;UnlockQueue&gt;
10.  
11.      assume esi:ptr _IRP
12.  
13.      mov [esi].IoStatus.Status, STATUS_SUCCESS
14.      mov [esi].IoStatus.Information, SOME_INFORMATION
15.  
16.      assume esi:nothing
17.  
18.      fastcall IofCompleteRequest, esi, IO_NO_INCREMENT
19.  
20.  

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

Код (Text):

1.  
2.  
3.  VOID
4.    ZeroIrpStackLocation(
5.      PIO_STACK_LOCATION pStack
6.      )
7.  {
8.      pStack->MinorFunction               = 0
9.      pStack->Flags                       = 0
10.      pStack->Control                     = 0
11.      pStack->Parameters.Others.Argument1 = 0
12.      pStack->Parameters.Others.Argument2 = 0
13.      pStack->Parameters.Others.Argument3 = 0
14.      pStack->Parameters.Others.Argument4 = 0
15.      pStack->FileObject                  = NULL
16.  }
17.  
18.  
19.  VOID
20.    IoCompleteRequest(
21.      IN PIRP  pIrp,
22.      IN CCHAR PriorityBoost
23.      )
24.  {
25.  
26.      NTSTATUS           status
27.      PIO_STACK_LOCATION pStack
28.  
29.      if  pIrp->CurrentLocation > pIrp->StackCount + 1  {
30.  
31.          KeBugCheckEx( MULTIPLE_IRP_COMPLETE_REQUESTS, ... )
32.      }
33.  
34.      ASSERT( pIrp->IoStatus.Status != STATUS_PENDING )
35.  
36.      pStack = IoGetCurrentIrpStackLocation( pIrp )
37.  
38.      pIrp->CurrentLocation++
39.      pIrp->Tail.Overlay.CurrentStackLocation += sizeof(IO_STACK_LOCATION)
40.  
41.      while  pIrp->CurrentLocation <= pIrp->StackCount + 1  {
42.  
43.          pIrp->PendingReturned = pStack->Control & SL_PENDING_RETURNED
44.  
45.          if  pIrp->IoStatus.Status == STATUS_SUCCESS  &&  pStack->Control & SL_INVOKE_ON_SUCCESS
46.                  ||
47.              pIrp->IoStatus.Status != STATUS_SUCCESS  &&  pStack->Control & SL_INVOKE_ON_ERROR
48.                  ||
49.              pIrp->Cancel == TRUE  &&  pStack->Control & SL_INVOKE_ON_CANCEL
50.          {
51.  
52.              ZeroIrpStackLocation( pStack )
53.  
54.              PDEVICE_OBJECT    pDeviceObject
55.  
56.              if  pIrp->CurrentLocation == pIrp->StackCount + 1  {
57.  
58.                  pDeviceObject = NULL
59.  
60.              }  else  {
61.  
62.                  pDeviceObject = IoGetCurrentIrpStackLocation( pIrp )->DeviceObject
63.              }
64.  
65.              status = pStack->CompletionRoutine( pDeviceObject, pIrp, pStack->Context )
66.  
67.              if  status == STATUS_MORE_PROCESSING_REQUIRED  {
68.  
69.                  return
70.              }
71.  
72.          }  else  {
73.  
74.              if  pIrp->PendingReturned  &&  pIrp->CurrentLocation <= pIrp->StackCount  {
75.  
76.                  IoMarkIrpPending( pIrp )
77.              }
78.  
79.              ZeroIrpStackLocation( pStack )
80.          }
81.  
82.          pStack += sizeof(IO_STACK_LOCATION)
83.  
84.          pIrp->CurrentLocation++
85.          pIrp->Tail.Overlay.CurrentStackLocation += sizeof(IO_STACK_LOCATION)
86.      }
87.  }
88.  
89.  

Рис. 15-6. Блок-схема функции IoCompleteRequest.

IoCompleteRequest должна пройтись по всем блокам стека, участвовавшим в обработке IRP, причем в обратном порядке, и вызвать все процедуры завершения. Когда IRP продвигается вниз, то значения полей CurrentLocation и CurrentStackLocation уменьшаются с каждым вызовом IoCallDriver (исключением является случай, когда драйвер передает свой собственный блок стека нижестоящему драйверу, пользуясь макросом IoSkipCurrentIrpStackLocation). IoCompleteRequest проделывает обратную работу, начиная с текущего блока стека, т.е. того, указатель на который находится в поле CurrentStackLocation (именно этот блок стека был текущим для драйвера вызвавшего IoCompleteRequest). Когда IoCompleteRequest "поднимется" до самого верха, значения этих двух полей будут такими же, какими они были сразу после вызова IoAllocateIrp. Т.е. значение в поле CurrentLocation должно быть на единицу больше чем StackCount, а CurrentStackLocation будет указывать на недействительный блок стека. Поэтому если CurrentLocation больше или равно StackCount + 1, это означает, что IRP уже был завершен. А завершать два раза IRP это примерно то же самое, что повторно вызывать ExFreePool с одним и тем же указателем. "Синий экран смерти" тут как нельзя кстати. Поэтому завершать IRP можно только один раз.

Дальше идет отладочное утверждение ASSERT. Код, заключенный в макрос ASSERT попадает только в отладочный выпуск (checked build) системы. В свободном выпуске (free build) системы отловить такой баг можно с помощью Driver Verifier. Я специально добавил эту строку, т.к. завершение IRP с кодом STATUS_PENDING - очень распространенная ошибка. IRP может либо завершаться, либо ожидать завершения. Третьего не дано.

Правило:

Завершать IRP с кодом STATUS_PENDING нельзя.

Далее IoCompleteRequest получает указатель на текущий блок стека, вызовом макроса IoGetCurrentIrpStackLocation. А какой блок стека текущий в данном случае? Сейчас текущим является блок стека, принадлежащий драйверу unknown. Ведь IRP продвигался вниз всего на "один шаг". Если бы драйверу unknown понадобился указатель на его блок стека, то вызовом IoGetCurrentIrpStackLocation, он получил бы тот же самый адрес.

Потом IoCompleteRequest крутит цикл, проходя по всем участвовавшим в обработке IRP блокам стека в обратном порядке. Если в блоке стека установлен флаг SL_PENDING_RETURNED, значит драйвер, которому он принадлежит, вызывал IoMarkIrpPending. Если это так, то устанавливается ненулевое значение в поле IRP.PendingReturned. А если флаг SL_PENDING_RETURNED не установлен, то поле IRP.PendingReturned обнуляется. Это нужно для того, чтобы вышестоящий драйвер в своей процедуре завершения смог видеть, что нижестоящий драйвер отмечал IRP как ожидающий завершения. Обращаться к чужим блокам стека драйверы не должны (исключение - копирование/заполнение блока стека при передаче IRP вниз по стеку). IoCompleteRequest даже специально обнуляет некоторые поля обработанного блока стека используя ZeroIrpStackLocation (на самом деле это макрос, а не функция). Поэтому SL_PENDING_RETURNED, как бы "перекладывается" в поле PendingReturned самого IRP. Когда мы доберемся до схемы на рис. 15-7, предназначение поля PendingReturned станет более понятно.

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

Если процедуре завершения потребуется обратиться к текущему блоку стека она тоже может использовать макрос IoGetCurrentIrpStackLocation. А какой блок стека она получит? Процедура завершения получит блок стека, принадлежащий её драйверу. Т.е. и в процедуре диспетчеризации и в процедуре завершения IoGetCurrentIrpStackLocation возвращает один и тот же указатель. Можем ли мы как создатели IRP в нашей процедуре завершения вызвать IoGetCurrentIrpStackLocation? Нет. Точнее указатель то мы получим, но на недействительный блок стека. Ведь своего собственного блока стека у нас нет, т.к. он нам не нужен.

Если процедура завершения вернула STATUS_MORE_PROCESSING_REQUIRED, то IoCompleteRequest, не делая ни одного лишнего движения, сразу возвращает управление, т.к. трогать IRP она уже не имеет права - возможно, IRP уже не существует. В нашем случае это именно так, ведь мы в процедуре завершения вызываем IoFreeIrp и для того, чтобы заставить IoCompleteRequest немедленно прекратить дальнейшие действия по завершению IRP, возвращаем STATUS_MORE_PROCESSING_REQUIRED. Если же процедура завершения возвращает любой другой код, то IoCompleteRequest продолжает работу. DDK рекомендует в качестве "любого другого кода" возвращать STATUS_SUCCESS просто потому, что он равен 0, а это приводит к генерации компилятором более оптимального кода. В более поздних DDK можно найти такие определения:

Код (Text):

1.  
2.  
3.  #define STATUS_CONTINUE_COMPLETION      STATUS_SUCCESS
4.  
5.  typedef enum _IO_COMPLETION_ROUTINE_RESULT {
6.      ContinueCompletion = STATUS_CONTINUE_COMPLETION,
7.      StopCompletion     = STATUS_MORE_PROCESSING_REQUIRED
8.  } IO_COMPLETION_ROUTINE_RESULT, *PIO_COMPLETION_ROUTINE_RESULT;
9.  
10.  

Имена констант ContinueCompletion и StopCompletion значительно лучше отражают суть, чем STATUS_SUCCESS и STATUS_MORE_PROCESSING_REQUIRED. Т.о., возвращая StopCompletion, мы говорим функции IoCompleteRequest, что она должна немедленно прекратить работу и вернуть управление. Если мы возвращаем ContinueCompletion (точнее говоря, не возвращаем StopCompletion), то IoCompleteRequest продолжает процесс завершения IRP.

Для чего нам нужно остановить IoCompleteRequest? Мы, как создатели IRP, не можем допустить, чтобы диспетчер в/в завершал созданный нами IRP. Это наша работа. Единственная возможность это сделать - установить процедуру завершения.

Если в обрабатываемом блоке стека нет указателя на процедуру завершения, то IoCompleteRequest смотрит, было ли установлено на предыдущем шаге поле IRP.PendingReturned. Если да, и всё ещё есть действительный блок стека, взводит флаг SL_PENDING_RETURNED в предыдущем блоке стека (этот блок IoCompleteRequest будет обрабатывать при следующем витке цикла), используя макрос IoMarkIrpPending.

Представим теперь два плохих сценария:

• драйвер unknown возвращает STATUS_PENDING, но забывает про IoMarkIrpPending;
• драйвер unknown отмечает IRP как ожидающий завершения, используя IoMarkIrpPending, но забывает вернуть STATUS_PENDING.

Сценарий 1: Если драйвер возвращает из процедуры диспетчеризации код STATUS_PENDING, IoCallDriver передаст этот код нам. Увидев такой код, мы бесконечно ждем, пока наша процедура завершения не освободит событие. По прошествии некоторого времени драйвер unknown инициирует завершение IRP. IoCompleteRequest смотрит в блок стека, принадлежащий драйверу unknown, и, не обнаружив там флага SL_PENDING_RETURNED, обнуляет IRP.PendingReturned. Видя, что в блоке стека установлена процедура завершения (установленная нашим драйвером), IoCompleteRequest вызывает её. Получив управление, наша процедура завершения не сигналит событие и освобождает память, занятую под IRP. В результате событие уже никогда не будет освобождено и поток, ожидающий на нем, никогда не возобновит работу.

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

Сценарий 2: Получив от IoCallDriver код отличный от STATUS_PENDING, наш драйвер считает, что IRP завершен и в зависимости от ошибочно возвращенного кода либо получает неверные данные, либо не получает ничего. Но это не самое страшное. Хуже, если мы переведем IoFreeIrp из процедуры завершения в основную процедуру после IoCallDriver, а мы имеем полное право это сделать. Драйвер unknown ведь не знает деталей реализации вышестоящего драйвера, и ни в коем случае не должен на это полагаться. Посчитав, что IRP завершен, мы вызовем IoFreeIrp. Через некоторое время драйвер unknown пытается извлечь уже не существующий IRP из очереди…

Не сложно догадаться, что для сценария 1 можно применить простое противоядие: вне зависимости от значения поля PendingReturned всегда вызывать KeSetEvent в процедуре завершения. Можно конечно, но тогда во всех случаях, когда IRP завершается немедленно, мы будем зря вызывать KeSetEvent, а она блокирует базу данных диспетчера потоков, ищет потоки, ждущие на событии, и делает их планируемыми, разблокирует базу данных диспетчера потоков. Вобщем, кое-какие накладные расходы будут. Но дело даже не в этом. Мы можем переписать нашу процедуру завершения, но мы не можем переписать код диспетчера в/в, который реализует свою логику работы. Диспетчер в/в вообще не устанавливает процедуру завершения. Он использует другие механизмы, но при принятии решений также опирается на код, возвращенный IoCallDriver и значение поля PendingReturned.

Правило:

Если из процедуры диспетчеризации драйвер возвращает код STATUS_PENDING, то перед этим должен вызвать IoMarkIrpPending. Если в процедуре диспетчеризации драйвер вызывает IoMarkIrpPending, то должен вернуть код STATUS_PENDING. Либо и то и другое, либо ни того, ни другого.

Вернемся к стеку клавиатуры. Мы уже вызвали IoCallDriver и сейчас находимся в процедуре диспетчеризации KeyboardPnP драйвера kbdclass.

Я использую здесь исходный код из 2003 IFS KIT. В 2000 DDK код функции KeyboardPnP отличается: драйвер kbdclass синхронизирует обработку IRP, используя функцию KeyboardSendIrpSynchronously, почти идентичную функции I8xSendIrpSynchronously драйвера i8042ptr (см. ниже). Во-первых, так нам будет проще, а во-вторых, это внесет некоторое разнообразие.

Код (Text):

1.  
2.  
3.      PIO_STACK_LOCATION    pStack
4.      NTSTATUS              status
5.  
6.      pStack = IoGetCurrentIrpStackLocation( pIrp )
7.  
8.      if  pStack->MinorFunction == IRP_MN_QUERY_PNP_DEVICE_STATE  {
9.  
10.          pIrp->IoStatus.Information |= PNP_DEVICE_NOT_DISABLEABLE
11.  
12.          pIrp->IoStatus.Status = STATUS_SUCCESS
13.  
14.          IoCopyCurrentIrpStackLocationToNext( pIrp )
15.          status = IoCallDriver( NextLowerDeviceObject, pIrp )
16.      }
17.  
18.      return status
19.  
20.  

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

При обработке IRP_MN_QUERY_PNP_DEVICE_STATE драйвер должен поместить в поле IRP.IoStatus.Information флаг, определяющий состояние устройства. При этом, поскольку поле IRP.IoStatus.Information одно, а драйверов в стеке много, все они используют логические операции для установки или сброса нужных флагов. Драйвер kbdclass добавляет флаг PNP_DEVICE_NOT_DISABLEABLE и помещает в IRP код успеха. Теперь он должен передать его нижестоящему драйверу. При этом дальнейшая судьба этого запроса его не интересует и он не устанавливает процедуру завершения. Уак будет завершен IRP, kbdclass не узнает уже никогда. Несмотря на то, что после вызова IoCallDriver в переменной pIrp всё еще будет хранится число, являвшееся указателем на IRP, обращаться по этому указателю драйвер kbdclass не имеет права, т.к., возможно, этот IRP уже не существует и на схеме 15-7 это будет очень хорошо видно.

Перед вызовом нижестоящего драйвера, драйвер kbdclass (и любой другой) должен заполнить причитающийся ему (нижестоящему драйверу) блок стека. В данном случае, т.к. kbdclass не формирует новый IRP, а пересылает переданный ему свыше, он может просто скопировать свой блок стека в следующий (помните, что это стек, где всё поставлено с ног на голову, т.е. следующим будет блок стека расположенный в памяти ниже). Это можно сделать с помощью макроса IoCopyCurrentIrpStackLocationToNext. В ntddk.inc можно увидеть оптимизированный вариант, а здесь приводится белее доступная для понимания версия.

Код (Text):

1.  
2.  
3.  IoCopyCurrentIrpStackLocationToNext MACRO pIrp:REQ
4.  
5.      push esi
6.      push edi
7.  
8.      mov eax, pIrp
9.  
10.      mov esi, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
11.  
12.      mov edx, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
13.      sub edx, sizeof IO_STACK_LOCATION
14.      mov edi, edx
15.  
16.      mov ecx, sizeof IO_STACK_LOCATION
17.  
18.      rep movsb
19.  
20.      and (IO_STACK_LOCATION PTR [edx]).Control, 0
21.      and (IO_STACK_LOCATION PTR [edx]).CompletionRoutine, 0
22.      and (IO_STACK_LOCATION PTR [edx]).Context, 0
23.  
24.      pop edi
25.      pop esi
26.  
27.  ENDM
28.  
29.  

Как видно, макрос копирует текущий блок стека в следующий, но три поля: Control, CompletionRoutine и Context обнуляются. Зачем обнуляются эти поля, мы знаем ниже. Теперь kbdclass вызывает IoCallDriver, передавая в своей переменной NextLowerDeviceObject, указатель на объект "устройство" находящийся непосредственно под ним. Этот указатель kbdclass получает при подключении к стеку. Т.к. мы договорились рассматривать классический состав стека, следующим в стеке оказывается объект "устройство", принадлежащий драйверу i8042ptr и мы оказываемся в его процедуре диспетчеризации I8xPnP.

Код (Text):

1.  
2.  
3.      PIO_STACK_LOCATION  pStack
4.      NTSTATUS            status
5.  
6.      pStack = IoGetCurrentIrpStackLocation( pIrp )
7.  
8.      if  pStack->MinorFunction == IRP_MN_QUERY_PNP_DEVICE_STATE  {
9.  
10.          status = I8xSendIrpSynchronously( TopOfStack, pIrp, FALSE )
11.  
12.          pIrp->IoStatus.Information |= PnpDeviceState
13.          pIrp->IoStatus.Status = status
14.  
15.          IoCompleteRequest( pIrp, IO_NO_INCREMENT )
16.      }
17.  
18.      return status;
19.  
20.  

i8042ptr также получает указатель на свой блок стека и синхронно перенаправляет IRP следующему (нижестоящему) драйверу acpi, указатель на который хранится в переменной TopOfStack.

Код (Text):

1.  
2.  
3.  NTSTATUS
4.  I8xPnPComplete (
5.      IN PDEVICE_OBJECT pDeviceObject,
6.      IN PIRP           pIrp,
7.      IN PKEVENT        pEvent
8.      )
9.  {
10.  
11.      KeSetEvent( pEvent, 0, FALSE )   // Four-F: It's not good to signal event unconditionaly.
12.  
13.      return STATUS_MORE_PROCESSING_REQUIRED
14.  }
15.  
16.  
17.  NTSTATUS
18.  I8xSendIrpSynchronously (
19.      IN PDEVICE_OBJECT pDeviceObject,
20.      IN PIRP           pIrp
21.      )
22.  {
23.      KEVENT   Event
24.      NTSTATUS status
25.  
26.      KeInitializeEvent( &event, SynchronizationEvent, FALSE )
27.  
28.      IoCopyCurrentIrpStackLocationToNext( pIrp )
29.  
30.      IoSetCompletionRoutine( pIrp, I8xPnPComplete, &Event, TRUE, TRUE, TRUE )
31.  
32.      status = IoCallDriver( pDeviceObject, pIrp )
33.  
34.      if  status == STATUS_PENDING  {
35.  
36.         KeWaitForSingleObject( &Event, Executive, KernelMode, FALSE, NULL )
37.  
38.         status = pIrp->IoStatus.Status
39.      }
40.  
41.      return status
42.  }
43.  
44.  

Разбирать функции I8xSendIrpSynchronously и I8xPnPComplete я не буду, т.к. они реализуют ту же логику работы, что и наши QueryPnpDeviceState и IrpComplete. Разобравшись с кодом нашего драйвера, вы без труда поймете, как работают эти две функции.

По возвращении из I8xSendIrpSynchronously, драйвер i8042ptr добавляет в поле Information свою порцию флагов из переменной PnpDeviceState и завершает IRP, вызовом IoCompleteRequest.

Ну, и, наконец, процедура диспетчеризации драйвера acpi будет у нас выглядеть так (на самом деле всё гораздо сложнее):

Код (Text):

1.  
2.  
3.  NTSTATUS
4.   SomeProc (
5.      IN PDEVICE_OBJECT pDeviceObject,
6.      IN PIRP           pIrp
7.      )
8.  {
9.  
10.      pIrp->IoStatus.Information |= PNP_DEVICE_NOT_DISABLEABLE
11.  
12.      pIrp->IoStatus.Status = STATUS_SUCCESS
13.  
14.      IoCompleteRequest( pIrp, IO_NO_INCREMENT )
15.  
16.      return STATUS_SUCCESS
17.  }
18.  
19.  

Теперь рассмотрим случай, когда обработка IRP будет синхронной, т.е. пройдет в контексте одного и того же потока. Все драйверы в стеке завершают IRP немедленно и, соответственно, ни одна из процедур диспетчеризации не возвращает STATUS_PENDING. Будем пользоваться схемой на рис. 15-7. Нарисовав эту схему, я был приятно удивлен тем, насколько хорошо видны на ней некоторые совсем неочевидные вещи.

Рис. 15-7. Этапы обработки IRP.

1. Наш драйвер QueryPnpDeviceState создает IRP, инициализирует объект "событие", на котором будет ждать завершения IRP, если завершение будет отложено, устанавливает процедуру завершения IrpComplete и посылает IRP драйверу kbdclass.

2. Драйвер kbdclass перенаправляет IRP нижестоящему драйверу i8042prt, не устанавливая процедуру завершения.

   Код (Text):

   1.  
   2.  
   3.  :irp -f 83887008
   4.  MdlAddress *         : 00000000
   5.  Flags                : 00000000
   6.  AssociatedIrp        : 00000000
   7.  &ThreadListEntry     : 83887018
   8.  IoStatus.Status      : C00000BB
   9.  IoStatus.Information : 00000000
   10.  RequestorMode        : 00
   11.  PendingReturned      : False
   12.  StackCount           : 05
   13.  CurrentLocation      : <b>04</b>
   14.  Cancel               : False
   15.  CancelIrql           : 00
   16.  ApcEnvironment       : 00
   17.  UserIosb *           : BE0A4C78
   18.  UserEvent *          : 00000000
   19.  Overlay              : 00000000 00000000
   20.  CancelRoutine *      : 00000000
   21.  UserBuffer *         : 00000000
   22.  Tail.Overlay
   23.         &DeviceQueueEntry : 83887048
   24.         Thread *          : 00000000
   25.         AuxiliaryBuffer * : 00000000
   26.         &ListEntry        : 83887060
   27.         CurrentStackLoc * : <b>838870E4</b>
   28.         OrigFileObject *  : 00000000
   29.  Tail.Apc *           : 83887048
   30.  Tail.ComplKey        : 00000000
   31.  
   32.  StackLocation 1 at 83887078:
   33.  <заполнен нулями>
   34.  
   35.  StackLocation 2 at 8388709C:
   36.  <заполнен нулями>
   37.  
   38.  StackLocation 3 at 838870C0:
   39.  <заполнен нулями>
   40.  
   41.  CurrentStackLocation at <b>838870E4</b>:
   42.  MajorFunction     : 1B IRP_MJ_PNP
   43.  MinorFunction     : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
   44.  Control           : 00
   45.  Flags             : 00
   46.  Others            : 00000000 00000000 00000000 00000000
   47.  DeviceObject *    : 81852CA0
   48.  FileObject *      : 00000000
   49.  CompletionRout *  : 00000000
   50.  Context *         : 00000000
   51.  
   52.  StackLocation 5 at 83887108:
   53.  MajorFunction     : 1B IRP_MJ_PNP
   54.  MinorFunction     : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
   55.  Control           : E0
   56.  Flags             : 00
   57.  Others            : 00000000 00000000 00000000 00000000
   58.  DeviceObject *    : 81852AB0
   59.  FileObject *      : 00000000
   60.  CompletionRout *  : ED5E14C0
   61.  Context *         : BE0A4C68
   62.  
   63.  

3. Драйвер i8042prt инициализирует объект "событие", на котором будет ждать завершения IRP, если завершение будет отложено, устанавливает процедуру завершения I8xPnpComplete и передаёт IRP нижестоящему драйверу acpi.

   Код (Text):

   1.  
   2.  
   3.  :irp -f 83887008
   4.  MdlAddress *         : 00000000
   5.  Flags                : 00000000
   6.  AssociatedIrp        : 00000000
   7.  &ThreadListEntry     : 83887018
   8.  IoStatus.Status      : C00000BB
   9.  IoStatus.Information : 00000000
   10.  RequestorMode        : 00
   11.  PendingReturned      : False
   12.  StackCount           : 05
   13.  CurrentLocation      : <b>03</b>
   14.  Cancel               : False
   15.  CancelIrql           : 00
   16.  ApcEnvironment       : 00
   17.  UserIosb *           : BE0A4C78
   18.  UserEvent *          : 00000000
   19.  Overlay              : 00000000 00000000
   20.  CancelRoutine *      : 00000000
   21.  UserBuffer *         : 00000000
   22.  Tail.Overlay
   23.         &DeviceQueueEntry : 83887048
   24.         Thread *          : 00000000
   25.         AuxiliaryBuffer * : 00000000
   26.         &ListEntry        : 83887060
   27.         CurrentStackLoc * : <b>838870C0</b>
   28.         OrigFileObject *  : 00000000
   29.  Tail.Apc *           : 83887048
   30.  Tail.ComplKey        : 00000000
   31.  
   32.  StackLocation 1 at 83887078:
   33.  <заполнен нулями>
   34.  
   35.  StackLocation 2 at 8388709C:
   36.  <заполнен нулями>
   37.  
   38.  CurrentStackLocation at <b>838870C0</b>:
   39.  MajorFunction     : 1B IRP_MJ_PNP
   40.  MinorFunction     : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
   41.  Control           : E0
   42.  Flags             : 00
   43.  Others            : 00000000 00000000 00000000 00000000
   44.  DeviceObject *    : 81852CA0
   45.  FileObject *      : 00000000
   46.  CompletionRout *  : ED09043F
   47.  Context *         : BE0A4B64
   48.  
   49.  StackLocation 4 at 838870E4:
   50.  MajorFunction     : 1B IRP_MJ_PNP
   51.  MinorFunction     : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
   52.  Control           : 00
   53.  Flags             : 00
   54.  Others            : 00000000 00000000 00000000 00000000
   55.  DeviceObject *    : 81852CA0
   56.  FileObject *      : 00000000
   57.  CompletionRout *  : 00000000
   58.  Context *         : 00000000
   59.  
   60.  StackLocation 5 at 83887108:
   61.  MajorFunction     : 1B IRP_MJ_PNP
   62.  MinorFunction     : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
   63.  Control           : E0
   64.  Flags             : 00
   65.  Others            : 00000000 00000000 00000000 00000000
   66.  DeviceObject *    : 81852AB0
   67.  FileObject *      : 00000000
   68.  CompletionRout *  : ED5E14C0
   69.  Context *         : BE0A4C68
   70.  
   71.  

4. Драйвер acpi завершает IRP (возможно предварительно разослав его каким-то другим драйверам), вызывая IoCompleteRequest.

   Функция IoCompleteRequest начинает завершение IRP. Смотрит в блок стека принадлежащий драйверу acpi. Не найдя там флага SL_PENDING_RETURNED (драйвер acpi не вызывал макрос IoMarkIrpPending), не устанавливает поле IRP.PendingReturned. Находит указатель на процедуру завершения I8xPnpComplete вышестоящего драйвера i8042prt и вызывает её.

   Код (Text):

   1.  
   2.  
   3.  :irp -f 83887008
   4.  MdlAddress *         : 00000000
   5.  Flags                : 00000000
   6.  AssociatedIrp        : 00000000
   7.  &ThreadListEntry     : 83887018
   8.  IoStatus.Status      : 00000000         <- STATUS_SUCCESS
   9.  IoStatus.Information : 00000020         <- PNP_DEVICE_NOT_DISABLEABLE
   10.  RequestorMode        : 00
   11.  PendingReturned      : False
   12.  StackCount           : 05
   13.  CurrentLocation      : <b>04</b>
   14.  Cancel               : False
   15.  CancelIrql           : 00
   16.  ApcEnvironment       : 00
   17.  UserIosb *           : BE0A4C78
   18.  UserEvent *          : 00000000
   19.  Overlay              : 00000000 00000000
   20.  CancelRoutine *      : 00000000
   21.  UserBuffer *         : 00000000
   22.  Tail.Overlay
   23.         &DeviceQueueEntry : 83887048
   24.         Thread *          : 00000000
   25.         AuxiliaryBuffer * : 00000000
   26.         &ListEntry        : 83887060
   27.         CurrentStackLoc * : <b>838870E4</b>
   28.         OrigFileObject *  : 00000000
   29.  Tail.Apc *           : 83887048
   30.  Tail.ComplKey        : 00000000
   31.  
   32.  StackLocation 1 at 83887078:
   33.  <заполнен нулями>
   34.  
   35.  StackLocation 2 at 8388709C:
   36.  <заполнен нулями>
   37.  
   38.  StackLocation 3 at 838870C0:
   39.  MajorFunction     : 1B IRP_MJ_PNP
   40.  MinorFunction     : 00                  <- обнулено ZeroIrpStackLocation
   41.  Control           : 00                  <- обнулено ZeroIrpStackLocation
   42.  Flags             : 00
   43.  Others            : 00000000 00000000 00000000 00000000
   44.  DeviceObject *    : 818A64F0
   45.  FileObject *      : 00000000
   46.  CompletionRout *  : ED09043F
   47.  Context *         : BE0A4B64
   48.  
   49.  CurrentStackLocation at <b>838870E4</b>:
   50.  MajorFunction     : 1B IRP_MJ_PNP
   51.  MinorFunction     : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
   52.  Control           : 00
   53.  Flags             : 00
   54.  Others            : 00000000 00000000 00000000 00000000
   55.  DeviceObject *    : 81852CA0
   56.  FileObject *      : 00000000
   57.  CompletionRout *  : 00000000
   58.  Context *         : 00000000
   59.  
   60.  StackLocation 5 at 83887108:
   61.  MajorFunction     : 1B IRP_MJ_PNP
   62.  MinorFunction     : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
   63.  Control           : E0
   64.  Flags             : 00
   65.  Others            : 00000000 00000000 00000000 00000000
   66.  DeviceObject *    : 81852AB0
   67.  FileObject *      : 00000000
   68.  CompletionRout *  : ED5E14C0
   69.  Context *         : BE0A4C68
   70.  
   71.  

5. Процедура завершения I8xPnpComplete совершенно напрасно сигналит событие (драйвер i8042prt не ждет и не будет ждать на этом событии) и возвращает код STATUS_MORE_PROCESSING_REQUIRED.

   Увидев код STATUS_MORE_PROCESSING_REQUIRED, IoCompleteRequest немедленно прекращает работу и возвращает управление в процедуру диспетчеризации драйвера acpi.

6. Драйвер acpi возвращает код STATUS_SUCCESS, и мы выходим из функции IoCallDriver в драйвере i8042prt.

   Увидев, что возвращенный из IoCallDriver код не STATUS_PENDING, драйвер i8042prt не ждет на событии. Сейчас драйвер i8042prt имеет полное право обращаться к IRP, т.к. устанавливал процедуру завершения, которая прервала обработку IRP. Поскольку драйвер i8042prt прервал завершение IRP, вернув из своей процедуры завершения код STATUS_MORE_PROCESSING_REQUIRED, то должен возобновить этот процесс. Что он и делает вызовом IoCompleteRequest.

   Выше мы выяснили, что завершать IRP два раза нельзя. Здесь же мы видим уже второй вызов IoCompleteRequest. Есть ли тут противоречие? Нет. Завершение IRP - это не просто вызов IoCompleteRequest. Это многоэтапный процесс. На каждом этапе он может быть прерван и возобновлен вновь. Только когда все эти этапы будут пройдены, IRP считается завершенным.

7. Функция IoCompleteRequest продолжает завершать IRP с того места, где её прервали, т.е. с текущего блока стека, а текущим сейчас является блок стека драйвера i8042prt. В блоке стека драйвера i8042prt нет флага SL_PENDING_RETURNED (драйвер i8042prt тоже не вызывал макрос IoMarkIrpPending). Поэтому IRP.PendingReturned опять обнуляется. IoCompleteRequest не находит указатель на процедуру завершения в блоке стека драйвера i8042prt и переходит к предыдущему и последнему блоку стека драйвера kbdclass. kbdclass тоже не использовал макрос IoMarkIrpPending и IRP.PendingReturned опять обнуляется. В блоке стека драйвера kbdclass имеется указатель на нашу процедуру завершения IrpComplete, которая и вызывается.

   Вспомните, что при передаче IRP нижестоящему драйверу, драйвер kbdclass скопировал свой блок стека в следующий, использую макрос IoCopyCurrentIrpStackLocationToNext. Однако этот макрос не копирует поля связанные с процедурой завершения. Если бы он этого не сделал, то указатель на нашу процедуру завершения (он находится в блоке стека драйвера kbdclass) попал бы в блок стека драйвера i8042prt, и наша процедура завершения была бы вызвана дважды. В стародавние времена, когда ещё не было макроса IoCopyCurrentIrpStackLocationToNext, программисты вручную копировали блоки стека, иногда забывая обнулить поля связанные с процедурой завершения, что приводило к трудно находимым багам.

   Код (Text):

   1.  
   2.  
   3.  :irp -f 83887008
   4.  MdlAddress *         : 00000000
   5.  Flags                : 00000000
   6.  AssociatedIrp        : 00000000
   7.  &ThreadListEntry     : 83887018
   8.  IoStatus.Status      : 00000000
   9.  IoStatus.Information : 00000020
   10.  RequestorMode        : 00
   11.  PendingReturned      : False
   12.  StackCount           : 05
   13.  CurrentLocation      : <b>06</b>
   14.  Cancel               : False
   15.  CancelIrql           : 00
   16.  ApcEnvironment       : 00
   17.  UserIosb *           : BE0A4C78
   18.  UserEvent *          : 00000000
   19.  Overlay              : 00000000 00000000
   20.  CancelRoutine *      : 00000000
   21.  UserBuffer *         : 00000000
   22.  Tail.Overlay
   23.         &DeviceQueueEntry : 83887048
   24.         Thread *          : 00000000
   25.         AuxiliaryBuffer * : 00000000
   26.         &ListEntry        : 83887060
   27.         CurrentStackLoc * : <b>8388712C</b>
   28.         OrigFileObject *  : 00000000
   29.  Tail.Apc *           : 83887048
   30.  Tail.ComplKey        : 00000000
   31.  
   32.  StackLocation 1 at 83887078:
   33.  <заполнен нулями>
   34.  
   35.  StackLocation 2 at 8388709C:
   36.  <заполнен нулями>
   37.  
   38.  StackLocation 3 at 838870C0:
   39.  MajorFunction     : 1B IRP_MJ_PNP
   40.  MinorFunction     : 00                 <- обнулено ZeroIrpStackLocation
   41.  Control           : 00                 <- обнулено ZeroIrpStackLocation
   42.  Flags             : 00
   43.  Others            : 00000000 00000000 00000000 00000000
   44.  DeviceObject *    : 818A64F0
   45.  FileObject *      : 00000000
   46.  CompletionRout *  : ED09043F
   47.  Context *         : BE0A4B64
   48.  
   49.  StackLocation 4 at 838870E4:
   50.  MajorFunction     : 1B IRP_MJ_PNP
   51.  MinorFunction     : 00                 <- обнулено ZeroIrpStackLocation
   52.  Control           : 00
   53.  Flags             : 00
   54.  Others            : 00000000 00000000 00000000 00000000
   55.  DeviceObject *    : 81852CA0
   56.  FileObject *      : 00000000
   57.  CompletionRout *  : 00000000
   58.  Context *         : 00000000
   59.  
   60.  StackLocation 5 at 83887108:
   61.  MajorFunction     : 1B IRP_MJ_PNP
   62.  MinorFunction     : 00                 <- обнулено ZeroIrpStackLocation
   63.  Control           : 00                 <- обнулено ZeroIrpStackLocation
   64.  Flags             : 00
   65.  Others            : 00000000 00000000 00000000 00000000
   66.  DeviceObject *    : 81852AB0
   67.  FileObject *      : 00000000
   68.  CompletionRout *  : ED5E14C0
   69.  Context *         : BE0A4C68
   70.  
   71.  CurrentStackLocation at <b>8388712C</b>:
   72.  <заполнен нулями>                      <- недействительный блок стека
   73.  
   74.  

   Наша процедура завершения несколько умнее. Видя, что поле PendingReturned равно нулю, она понимает, что нижестоящий драйвер не возвращал STATUS_PENDING, а значит, процедура диспетчеризации драйвера QueryPnpDeviceState не ждет на событии. Поэтому и сигналить его нет смысла. Мы установили процедуру завершения только для того, чтобы удалить, созданный нами IRP. Можем сделать это прямо сейчас, вызвав IoFreeIrp. Поскольку IRP больше нет, мы должны остановить его завершение, вернув код STATUS_MORE_PROCESSING_REQUIRED.

8. Увидев код STATUS_MORE_PROCESSING_REQUIRED, IoCompleteRequest немедленно прекращает работу и возвращает управление в процедуру диспетчеризации драйвера i8042prt. Вот здесь очень хорошо видно, почему после вызова IoCompleteRequest нельзя обращаться к IRP. Ведь возможно IRP уже не существует, и узнать это драйвер вызывающий IoCompleteRequest не может. Обратите внимание на то, что функция IoCompleteRequest не возвращает никакого значения.

   Правило:

   После вызова процедуры IoCompleteRequest обращаться к IRP нельзя. Возможно, IRP уже не существует.

9. Процедура диспетчеризации драйвера i8042prt возвращает код, который вернула вызванная им IoCallDriver, а это, в данном случае, STATUS_SUCCESS и мы выходим из функции IoCallDriver в драйвере kbdclass. И опять здесь хорошо видно, почему после вызова IoCallDriver нельзя обращаться к IRP, если, конечно, не устанавливать процедуру завершения и не прерывать завершение IRP. Ведь IRP то уже не существует. Драйвер kbdclass отказался от установки процедуры завершения, а значит, после вызова IoCallDriver полностью потерял контроль над IRP. Кто и когда завершит IRP драйвер kbdclass не узнает, а значит, не может делать никаких предположений о том, существует ли IRP до сих пор или его уже нет. Драйвер i8042prt смог обратиться к IRP после вызова IoCallDriver только потому, что его процедура завершения прервала процесс завершения IRP, а драйвер kbdclass не может.

   Правило:

   Если у вас нет процедуры завершения или имеющаяся у вас процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то после вызова IoCallDriver обращаться к IRP нельзя. Возможно, IRP уже не существует.

10. Процедура диспетчеризации драйвера kbdclass возвращает код, который вернула, вызванная им, IoCallDriver, а это, в данном случае, STATUS_SUCCESS и мы выходим из функции IoCallDriver в нашем драйвере QueryPnpDeviceState.

    Видя, что возвращенный из IoCallDriver код не STATUS_PENDING, мы не ждем на событии. Хотя мы и установили процедуру завершения, и она вернула STATUS_MORE_PROCESSING_REQUIRED, но трогать IRP после возвращения из IoCallDriver всё равно не можем. Это исключение из правил, т.к. мы являемся создателем IRP. Надеюсь, здесь это очевидно. Мы же сами удалили IRP в процедуре завершения и прекратили его дальнейшее завершение.

Теперь поставим на место драйвера acpi драйвер unknown и представим, что он откладывает завершение IRP и возвращает из своей процедуры диспетчеризации STATUS_PENDING. Т.е. обработка IRP будет асинхронной.

Т.к. драйвер unknown откладывает завершение IRP, то, используя макрос IoMarkIrpPending, заносит в свой блок стека флаг SL_PENDING_RETURNED, ставит IRP в очередь и возвращает STATUS_PENDING. Мы выходим из функции IoCallDriver в драйвере i8042prt. Увидев код STATUS_PENDING, драйвер i8042prt начинает ждать освобождения события и текущий поток блокируется.

Через некоторое время в результате прерывания или по другой причине, но в контексте какого-то другого потока, драйвер unknown достает IRP из очереди и завершает его вызовом IoCompleteRequest. IoCompleteRequest обнаруживает в блоке стека драйвера unknown флаг SL_PENDING_RETURNED, и поле IRP.PendingReturned принимает ненулевое значение. Обнаружив указатель на процедуру завершения I8xPnpComplete вышестоящего драйвера i8042prt, вызывает её. Процедура завершения I8xPnpComplete сигналит событие и возвращает код STATUS_MORE_PROCESSING_REQUIRED, что заставляет функцию IoCompleteRequest прекратить работу и вернуться туда, откуда она была вызвана.

Ожидающий на событии поток пробуждается. Сейчас драйвер i8042prt имеет полное право обращаться к IRP, т.к. прервал завершение IRP, вернув из своей процедуры завершения код STATUS_MORE_PROCESSING_REQUIRED, и совершенно точно знает, что IRP ещё не завершен. Это он и делает, для того чтобы узнать код, с которым завершился отложенный IRP (см. исходный код функции I8xSendIrpSynchronously). Этот код драйвер извлекает из поля IRP.IoStatus.Status и из своей процедуры диспетчеризации будет возвращать именно его, а не первоначальный STATUS_PENDING. Затем драйвер i8042prt возобновляет завершение IRP, вызовом IoCompleteRequest.

Функция IoCompleteRequest продолжает завершать IRP с того места, где её прервали, т.е. с текущего блока стека, а текущим сейчас является блок стека драйвера i8042prt. В этом блоке стека нет флага SL_PENDING_RETURNED… Точнее говоря, его там быть не должно, но взгляните на исходный код функции I8xPnPComplete из 2000 DDK. Вы увидите там такие строки:

Код (Text):

1.  
2.  
3.  w2000:
4.  
5.  NTSTATUS
6.    I8xPnPComplete (
7.      IN PDEVICE_OBJECT pDeviceObject,
8.      IN PIRP           pIrp,
9.      IN PKEVENT        pEvent
10.      )
11.  {
12.  
13. <FONT color="red">     if  pIrp->PendingReturned  {
14.  
15.          IoMarkIrpPending( pIrp )     // Four-F: Do not do this if you return
16.                                       //         STATUS_MORE_PROCESSING_REQUIRED!
17.      }</FONT>
18.  
19.      KeSetEvent( pEvent, 0, FALSE )   // Four-F: It's not good to signal event unconditionaly.
20.      return STATUS_MORE_PROCESSING_REQUIRED
21.  }
22.  
23.  

В 2003 DDK эти строки уже закомментарены.

Код (Text):

1.  
2.  
3.  wnet:
4.  
5.  NTSTATUS
6.    I8xPnPComplete (
7.      IN PDEVICE_OBJECT pDeviceObject,
8.      IN PIRP           pIrp,
9.      IN PKEVENT        pEvent
10.      )
11.  {
12.  
13. <FONT color="red">     //
14.      // Since this completion routines sole purpose in life is to synchronize
15.      // Irp, we know that unless something else happens that the IoCallDriver
16.      // will unwind AFTER the we have complete this Irp.  Therefore we should
17.      // NOT bubble up the pending bit.
18.      //
19.      // if  pIrp->PendingReturned  {
20.      //     IoMarkIrpPending( pIrp )
21.      // }
22.      //</FONT>
23.  
24.      KeSetEvent( pEvent, 0, FALSE )   // Four-F: It's not good to signal event unconditionaly.
25.      return STATUS_MORE_PROCESSING_REQUIRED
26.  }
27.  
28.  

Две выделенные красным строки должны быть в процедуре завершения, но только если она не возвращает STATUS_MORE_PROCESSING_REQUIRED. Чуть позже увидим почему.

Допустим, мы используем I8xPnPComplete из 2000 DDK и в блоке стека драйвера i8042prt ошибочно присутствует флаг SL_PENDING_RETURNED. Видя это, IoCompleteRequest опять помещает в поле IRP.PendingReturned ненулевое значение. Если вы проанализируете дальнейший ход событий, то увидите, что ненулевое значение в поле IRP.PendingReturned дойдет до нашей процедуры завершения. Увидев не равное нулю поле IRP.PendingReturned, она решит, что нижестоящий драйвер вернул STATUS_PENDING и процедура диспетчеризации QueryPnpDeviceState ждет освобождения события, хотя на самом деле это не так. В данном случае, ничего ужасного не произойдет. Мы просто напрасно просигналим событие и всё. В каком-то другом случае, наверное, возможны более серьёзные последствия, т.к. драйвер будет основывать свои действия на неверных допущениях.

Мы уже несколько раз убеждались в том, что не стоит слепо верить документации DDK. Теперь оказывается, что и исходникам DDK нельзя верить?! Да, к сожалению, это так. Особенно много, скажем так, неоптимальных решений в исходниках 2000 DDK. Тексту этой статьи я тоже, кстати, советую не доверять В конце концов, все мы люди, а людям, как известно…

Остальные возможные сценарии проанализируйте сами. Я только хочу ещё раз обратить особое внимание на поле IRP.PendingReturned. Во всех источниках, которые мне приходилось видеть, в том числе и в DDK, предназначение этого поля не совсем верно трактуется. Обычно говорится, что это поле сообщает диспетчеру в/в или вышестоящему драйверу о том, что нижестоящий драйвер отмечал IRP как ожидающий завершения (вызывал IoMarkIrpPending и возвращал из процедуры диспетчеризации STATUS_PENDING). Это верно. Также говорится, что якобы если какой-либо драйвер отмечал IRP как ожидающий завершения, то ненулевое значение этого поля так и сохраняется при завершении IRP до самого верха. А вот это уже не совсем так. Функция IoCompleteRequest (и мы с вами тоже должны будем принять в этом участие чуть ниже) действительно старается сохранить состояние этого поля, но только если она не встретит процедуру завершения. Зачем это нужно? В только что рассмотренном нами сценарии с драйвером unknown вместо acpi, обработка IRP до того как он опустился до драйвера i8042prt, была синхронной (проходила в контексте одного и того же потока). После того, как драйвер unknown вернул из процедуры диспетчеризации STATUS_PENDING, обработка IRP стала асинхронной (процедура завершения драйвера i8042prt вызывается в контексте случайного потока, а процедура диспетчеризации драйвера i8042prt ждет события в контексте первоначального потока). Дождавшись освобождения события, процедура диспетчеризации драйвера i8042prt продолжает обработку IRP в контексте первоначального потока, и обработка IRP опять становится синхронной. Вот тут собака и зарыта. Все драйверы находящиеся выше i8042prt вообще не должны знать, что драйвер unknown откладывал завершение IRP. Это проблема драйвера i8042prt и он сам её решил. Для всех вышестоящих драйверов всё как было синхронным, так и осталось. На участке между драйверами unknown и i8042prt поле IRP.PendingReturned будет содержать ненулевое значение, а на участке выше драйвера i8042prt оно обнулится, т.к. обработка IRP вновь стала синхронной и никто никого не ждет. Надеюсь, что понятно объяснил и нигде не ошибся

Ну, хорошо, все процедуры завершения, которые мы видели до сих пор, возвращали STATUS_MORE_PROCESSING_REQUIRED. Но, как мы выяснили выше, это не единственно возможный код возврата. Этот код процедуры завершения возвращают в одном из трех случаев:

1. Драйвер-создатель IRP вновь хочет увидеть своё чадо, для того чтобы его… скажем мягко, освободить (пример - наш драйвер) или повторно использовать;
2. Драйвер хочет синхронизировать обработку IRP (пример - драйвер i8042prt);
3. Т.к. процедура завершения может вызываться на повышенном IRQL, драйвер хочет сделать какую-то дополнительную обработку на PASSIVE_LEVEL в своей процедуре диспетчеризации.

Если же драйверу не нужна такая функциональность, но перехватить IRP на обратном пути всё же требуется (например, для того, чтобы посмотреть считанные с диска данные или код нажатой клавиши, что мы и будем делать в следующей статье) и всю обработку драйвер может сделать в процедуре завершения, даже на уровне DISPATCH_LEVEL, то тогда процедуре завершения не требуется прерывать завершение IRP и можно вернуть STATUS_SUCCESS или ContinueCompletion (что одно и то же).

В этом случае процедура завершения может выглядеть примерно так:

Код (Text):

1.  
2.  
3.  JustComplete proc uses esi edi ebx pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP, pContext:PVOID
4.  
5.      mov esi, pIrp
6.      assume esi:ptr _IRP
7.  
8.      .if [esi].IoStatus.Status == STATUS_SUCCESS
9.        
10.          mov edi, [esi].AssociatedIrp.SystemBuffer
11.          assume edi:ptr SOME_DATA
12.        
13.          ; Что-то делаем с данными
14.  
15.          assume edi:nothing
16.    
17.      .endif
18.    
19.      .if [esi].PendingReturned
20.          IoMarkIrpPending esi
21.      .endif
22.  
23.      assume esi:nothing
24.  
25.      mov eax, STATUS_SUCCESS
26.      ret
27.  
28.  JustComplete endp
29.  
30.  

Самое важное здесь, в контексте нашего разговора, это вызов макроса IoMarkIrpPending в случае, если поле IRP.PendingReturned не равно нулю. Выше мы разобрались, что IoCompleteRequest как бы "перекладывает" флаг SL_PENDING_RETURNED из текущего блока стека в поле PendingReturned самого IRP и наоборот, если в блоке стека нет процедуры завершения, а поле PendingReturned не равно нулю, то вызывает макрос IoMarkIrpPending. Короче говоря, IoCompleteRequest пытается донести до первой встретившейся ей процедуры завершения, тот факт, что какой-то нижестоящий драйвер отмечал IRP как ожидающий завершения. Когда IoCompleteRequest находит процедуру завершения, то возлагает эту задачу на неё (см. исходный код IoCompleteRequest, а лучше блок-схему).

Представим, что вместо драйвера acpi у нас драйвер unknown и процедура завершения I8xPnPComplete драйвера i8042prt похожа на процедуру JustComplete, т.е. не сигналит событие и возвращает код STATUS_SUCCESS. Соответственно, процедура диспетчеризации драйвера i8042prt никакого события не инициализирует и не ждет, а просто возвращает тот код, который вернет IoCallDriver.

Драйвер unknown вызывает макрос IoMarkIrpPending, ставит IRP в очередь и возвращает STATUS_PENDING. Этот код "поднимается" до нашей процедуры диспетчеризации и мы начинаем ждать.

Некоторое время спустя, в результате прерывания или по другой причине, но в контексте какого-то другого потока, драйвер unknown извлекает IRP из очереди и завершает его вызовом IoCompleteRequest. IoCompleteRequest обнаруживает в блоке стека драйвера unknown флаг SL_PENDING_RETURNED, и поле IRP.PendingReturned принимает ненулевое значение. Обнаружив указатель на процедуру завершения JustComplete вышестоящего драйвера i8042prt, вызывает её (повторяю, мы заменили код на JustComplete). Сделав свои дела, процедура завершения JustComplete видит, что поле IRP.PendingReturned не равно нулю и, вызовом макроса IoMarkIrpPending, кладет в свой блок стека флаг SL_PENDING_RETURNED. Функция IoCompleteRequest делает то же самое в ветке else, но т.к. IoCompleteRequest встретила процедуру завершения, то эта задача перекладывается на неё. Т.к. процедура завершения I8xPnpComplete возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, функция IoCompleteRequest продолжает "подниматься" по блокам стека. Сделав дальнейший анализ, вы увидите, что информация о том, что IRP отмечался как ожидающий завершения в виде ненулевого значения в поле IRP.PendingReturned благополучно доходит до нашей процедуры завершения. Наша процедура завершения понимает, что процедура диспетчеризации QueryPnpDeviceState ждет на событии, сигналит его и всё заканчивается благополучно.

А если вы также проанализируете, что будет, если процедура завершения JustComplete забудет должным образом воспользоваться макросом IoMarkIrpPending, то придете к ещё одному правилу.

Правило:

Если процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то должна использовать (в любо месте) макрос IoMarkIrpPending таким образом. if pIrp->PendingReturned { IoMarkIrpPending( pIrp ) }

Ну и последнее. Т.к. у процедуры завершения нет другой возможности узнать, с каким кодом нижестоящий драйвер завершает IRP, кроме как обратиться к полю IRP.IoStatus.Status, мы запишем последнее правило.

Правило:

Перед вызовом IoCompleteRequest в процедуре диспетчеризации драйвер должен поместить в поле IRP.IoStatus.Status код с которым он завершает IRP и вернуть из процедуры диспетчеризации тот же самый код.

Начиная писать эту "бесконечную" статью я планировал ещё рассказать о том, какую логику использует диспетчер в/в при обработке IRP, т.к. чаще всего именно он является создателем IRP, но чувствую, что силы покидают меня. Если этот вопрос вас интересует, то рекомендую почитать статью "How Windows NT Handles I/O Completion" в IFS KIT или "The NT Insider" ( http://www.osronline.com/ ). К сожалению, исходного кода диспетчера в/в вы там не найдете, но общее представление получите.

Что вы должны делать и чего вы делать не должны

Подведем итог.

Правило 1:

Перед вызовом IoCompleteRequest в процедуре диспетчеризации драйвер должен поместить в поле IRP.IoStatus.Status код с которым он завершает IRP и вернуть из процедуры диспетчеризации тот же самый код.

Правило 2:

После вызова процедуры IoCompleteRequest обращаться к IRP нельзя. Возможно, IRP уже не существует.

Правило 3:

Завершать IRP с кодом STATUS_PENDING нельзя.

Правило 4:

Если из процедуры диспетчеризации драйвер возвращает код STATUS_PENDING, то перед этим должен вызвать IoMarkIrpPending. Если в процедуре диспетчеризации драйвер вызывает IoMarkIrpPending, то должен вернуть код STATUS_PENDING. Либо и то и другое, либо ни того, ни другого.

Правило 5:

Если у вас нет процедуры завершения или имеющаяся у вас процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то после вызова IoCallDriver обращаться к IRP нельзя. Возможно, IRP уже не существует.

Правило 6:

Если процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то должна использовать (в любо месте) макрос IoMarkIrpPending таким образом. if pIrp->PendingReturned { IoMarkIrpPending( pIrp ) }

Некоторые из этих правил, наверное, можно нарушить, если очень хорошо представлять себе, все детали механизма обработки IRP. Если такого представления нет, то лучше следовать им неукоснительно.

В следующий раз мы попробуем применить кое-какие полученные сегодня знания на практике.

Исходный код драйвера в архиве.

© Four-F