Драйверы режима ядра: Часть 16 : Драйвер-фильтр (не PnP) — Архив WASM.RU
Эта статья является практическим дополнением предыдущей, где мы рассмотрели жизненный цикл IRP. Без прочтения предыдущей статьи будет трудно до конца понять материал этой. Если вы используете USB-мышь или клавиатуру у вас, к сожалению, могут возникнуть некоторые трудности (см. конец статьи).
Стек клавиатуры
Для начала совсем чуть-чуть теории о том, как функционирует стек клавиатуры.
Физическую связь клавиатуры с шиной осуществляет микроконтроллер клавиатуры Intel 8042 (или совместимый с ним). На современных компьютерах он интегрирован в чипсет материнской платы. Этот контроллер может работать в двух режимах: AT-совместимом и PS/2-совместимом. AT-клавиатуру, сейчас, наверное, уже сложно найти. Все клавиатуры уже давно являются PS/2-совместимыми или клавиатурами, подключаемыми через интерфейс USB. В PS/2-совместимом режиме микроконтроллер клавиатуры также связывает с шиной и PS/2-совместимую мышь. Всем этим хозяйством управляет функциональный драйвер i8042prt (Intel 8042 Port Driver), полный исходный код которого, можно найти в DDK (DDK\src\input\pnpi8042). Драйвер i8042prt создает два безымянных объекта "устройство" и подключает один к стеку клавиатуры, а другой к стеку мыши. В прошлой статье на рисунке 15-4 вы видели, что на машине с системой Terminal Server у клавиатуры (и у мыши тоже) имеется более одного (определяется количеством терминальных сессий) стека. На "обычной" машине клавиатурный и "мышиный" стеки выглядят примерно так:
Код (Text):
Поверх драйвера i8042prt, точнее поверх его устройств, располагаются именованные объекты "устройство" драйверов Kbdclass и Mouclass. Имя "KeyboardClass" является базовым, и к нему добавляются индексы (0, 1 и т.д.). Базовое имя хранится в параметре реестра HKLM\SYSTEM\CurrentControlSet\Services\Kbdclass\Parameters\KeyboardDeviceBaseName и может быть также "KeyboardPort" в случае если клавиатура использует унаследованные (legacy) драйверы, хотя подробно я в этом не разбирался (см. исходный код драйвера Kbdclass). Мы будем использовать в качестве устройства-цели для подключения фильтра объект "устройство" под именем "KeyboardClass0".
Драйверы Kbdclass и Mouclass являются так называемыми драйверами класса (class drivers) и реализуют общую функциональность для всех типов клавиатур и мышей, т.е. для всего класса этих устройств. Оба эти драйвера устанавливаются как высокоуровневые драйверы фильтры и их полный исходный код также можно найти в DDK (DDK\src\input\kbdclass и DDK\src\input\mouclass, соответственно). В архиве к этой статье в каталоге SetKeyboardLeds находится простейший драйвер, зажигающий все три индикатора клавиатуры. Примерно так (т.е. через порты ввода/вывода) функциональный драйвер i8042prt управляет устройством "клавиатура". В исходном коде драйверов Kbdclass и Mouclass обращения к портам вы конечно не найдете.
Стек клавиатуры обрабатывает несколько типов запросов (полный список см. в разделе DDK "Kbdclass Major I/O Requests"). Нас будут интересовать только IRP типа IRP_MJ_READ, которые несут с собой коды клавиш. Генератором этих IRP является поток необработанного ввода RawInputThread системного процесса csrcc.exe. Этот поток открывает объект "устройство" драйвера класса клавиатуры для эксклюзивного использования и с помощью функции ZwReadFile направляет ему IRP типа IRP_MJ_READ. Получив IRP, драйвер Kbdclass, используя макрос IoMarkIrpPending, отмечает его как ожидающий завершения (pending), ставит в очередь и возвращает STATUS_PENDING. Потоку необработанного ввода придется ждать завершения IRP (если точнее, то RawInputThread получает клавиатурные события как вызов асинхронной процедуры (Asynchronous Procedure Call, APC)). Подключаясь к стеку, драйвер Kbdclass регистрирует у драйвера i8042prt процедуру обратного вызова KeyboardClassServiceCallback, направляя ему IRP IOCTL_INTERNAL_KEYBOARD_CONNECT. Драйвер i8042prt тоже регистрирует у системы свою процедуру обработки прерывания (Interrupt Service Routine, ISR) I8042KeyboardInterruptService, вызовом функции IoConnectInterrupt. Когда будет нажата или отпущена клавиша, контроллер клавиатуры выработает аппаратное прерывание. Его обработчик вызовет I8042KeyboardInterruptService, которая прочитает из внутренней очереди контроллера клавиатуры необходимые данные. Т.к. обработка аппаратного прерывания происходит на повышенном IRQL, ISR делает только самую неотложную работу и ставит в очередь вызов отложенной процедуры (Deferred Procedure Call, DPC). DPC работает при IRQL = DISPATCH_LEVEL. Когда IRQL понизится до DISPATCH_LEVEL, система вызовет процедуру I8042KeyboardIsrDpc, которая вызовет зарегистрированную драйвером Kbdclass процедуру обратного вызова KeyboardClassServiceCallback (также выполняется на IRQL = DISPATCH_LEVEL). KeyboardClassServiceCallback извлечет из своей очереди ожидающий завершения IRP, заполнит структуру KEYBOARD_INPUT_DATA (на самом деле i8042prt старается опустошить всю очередь контроллера клавиатуры, а Kbdclass соответственно заполнить столько структур KEYBOARD_INPUT_DATA, сколько влезет в буфер IRP), несущую всю необходимую информацию о нажатиях/отпусканиях клавиш и завершит IRP. Поток необработанного ввода пробуждается, обрабатывает полученную информацию и вновь посылает IRP типа IRP_MJ_READ драйверу класса, который опять ставится в очередь до следующего нажатия/отпускания клавиши. Таким образом, у стека клавиатуры всегда есть, по крайней мере, один, ожидающий завершения IRP и находится он в очереди драйвера Kbdclass. "Мышиный" стек ведет себя подобным же образом.
Код (Text):
Как видно, драйвер Kbdclass имеет незавершенный IRP типа IRP_MJ_READ (цифра 3 в квадратных скобках). Колонка cl показывает содержимое поля IO_STACK_LOCATION.Control. В данном случае это флаг SL_PENDING_RETURNED, установленный вызовом макроса IoMarkIrpPending. Строка Args представляет собой содержимое вложенной структуры IO_STACK_LOCATION.Read. Размер буфера (78h) достаточен ровно для 10 структур KEYBOARD_INPUT_DATA. Сам буфер находится по адресу System buffer = 81664b48. Обратите также внимание на строку CancelRoutine = f3ec82e0. Это адрес процедуры отмены IRP (cancel routine), принадлежащей драйверу Kbdclass. Отмена IRP - это ещё одна большая и относительно сложная тема (которую я не планирую освещать). Позже мы немного поговорим об этом.
Этот, ожидающий завершения, IRP, естественно, принадлежит потоку RawInputThread.
Код (Text):
Когда мы установим фильтр, то IRP сначала будут попадать к нам. Т.к. IRP типа IRP_MJ_READ является фактически запросом на чтение данных, то когда он идет вниз по стеку его буфер, естественно пуст. Прочитанный данные буфер будет содержать только после завершения IRP. Для того чтобы их (данные) увидеть фильтр должен установить в каждый IRP (точнее в свой блок стека) процедуру завершения. Т.к. находящийся в очереди драйвера Kbdclass IRP был послан до того, как мы установим фильтр, то в нем нет нашей процедуры завершения, а значит, мы никак не сможем увидеть код той клавиши, которая будет нажата сразу после установки фильтра. Когда клавиша будет нажата, ожидающий завершения IRP будет завершен и RawInputThread пошлет новый IRP типа IRP_MJ_READ. Этот и все последующие IRP мы уже перехватим и поставим процедуру завершения. Когда клавиша будет отпущена, мы прочитаем в процедуре завершения её код. Именно поэтому фильтр не видит момента нажатия на первую клавишу, и в мониторе вы всегда будете видеть для первой нажатой клавиши только её код break (отпускание клавиши). Дальше фильтр перехватывает все нажатия и все отпускания любых клавиш.
Прежде чем мы перейдем к коду драйвера, разберемся ещё с несколькими моментами.
Спин-блокировка
Поскольку обработка IRP по своей природе асинхронна, то зачастую "правая рука не знает, что делает левая". Поэтому в каждом более-менее серьезном драйвере приходится использовать механизм синхронизации под названием "взаимоисключающий доступ". В тринадцатой части цикла - "Базовая техника. Синхронизация: Взаимоисключающий доступ" мы уже познакомились с тем, как организовать взаимоисключающий доступ с помощью мьютекса. Поэтому про макросы MUTEX_INIT, MUTEX_ACQUIRE и MUTEX_RELEASE, которые мы вновь будем использовать, я молчу.
Синхронизация с помощью мьютекса удобна, но, к сожалению, у нее есть один недостаток: как известно, ожидать объекты на IRQL равном DISPATCH_LEVEL и выше нельзя. Для организации взаимоисключающего доступа на IRQL до DISPATCH_LEVEL включительно существует механизм под названием "спин-блокировка" (spin lock).
Код (Text):
На однопроцессорной машине захват спин-блокировки заключается в простом повышении IRQL до DISPATCH_LEVEL. Как известно, на этом IRQL не происходит планирования потоков, и поток, владеющий процессором, будет выполняться до тех пор, пока IRQL не понизится. Поскольку IRQL является атрибутом процессора, на многопроцессорной машине простого повышения IRQL не достаточно, т.к. это не блокирует потоки, выполняющиеся другими процессорами. Поэтому в многопроцессорных HAL спин-блокировка реализована несколько сложнее и является спин-блокировкой в истинном смысле этого слова (spin - крутить, вертеть; пускать волчок). Т.е. если блокировка занята, поток крутит бесконечный цикл, пытаясь её захватить. При этом т.к. цикл выполняется на IRQL = DISPATCH_LEVEL, планирования потоков на этом процессоре не происходит и процессор не может заняться полезной работой. Именно поэтому спин-блокировки гораздо более критичны ко времени. Т.е. освободить спин-блокировку нужно как можно быстрее. DDK даже определяет максимальный временной интервал в 25 микросекунд, в течении которого можно держать спин-блокировку. В этом смысле мьютексы и другие объекты ожидания менее требовательны, т.к. поток, ожидающий занятый объект, просто исключается из планирования, и процессор получает другой, готовый к выполнению поток.
И раз уж нам пришлось коснуться спин-блокировки, то запомните несколько классических правил. Во-первых, захват спин-блокировки, как мы только что выяснили, повышает IRQL до DISPATCH_LEVEL, а значит, нам доступна только неподкачиваемая память и сам код также должен находиться в неподкачиваемой памяти. Во-вторых, повторный захват той же самой спин-блокировки, естественно, приведет к полной блокировке (deadlock). В третьих, захватывать спин-блокировку на IRQL выше DISPATCH_LEVEL нельзя, т.к. это фактически означает явное понижение IRQL, что неминуемо приведет к BSOD. В-четвертых, если требуется захватить две (или больше) спин-блокировки, то все потоки должны это делать в одном и том же порядке. Иначе возможна взаимная блокировка. Например, двум потокам требуется захватить блокировки A и B. Если они будут делать это в разном порядке, то, возможно, что в одно и то же время первый поток захватит блокировку A, а второй блокировку B. После этого оба потоку будут бесконечно ждать: первый - когда освободится блокировка B, а второй - когда освободиться блокировка A.
Код (Text):
Для захвата спин-блокировки будем использовать макросы. Это упрощенные версии. В макросе LOCK_RELEASE мы используем небольшую оптимизацию: если мы были до захвата спин-блокировки на IRQL = DISPATCH_LEVEL, то выгоднее вызвать KefReleaseSpinLockFromDpcLevel вместо KfReleaseSpinLock, т.к. изменять IRQL не требуется и на однопроцессорной машине KefReleaseSpinLockFromDpcLevel является "пустой" функцией.
Код (Text):
Нечто подобное (я имею в виду оптимизацию) можно сделать и для макроса LOCK_ACQUIRE. Потребуется только узнать текущий IRQL и если он равен DISPATCH_LEVEL, то вызвать KeAcquireSpinLockAtDpcLevel, которая (на однопроцессорной машине) тоже выполняет инструкцию ret.
Код (Text):
Я не стал оптимизировать макрос LOCK_ACQUIRE, т.к. написал эти макросы давно и несколько раз успешно использовал, к тому же не ясно, что быстрее: просто вызвать KfAcquireSpinLock или выяснять IRQL и в зависимости от его значения вызывать KeAcquireSpinLockAtDpcLevel. Поэтому я не стал ничего мудрить и оставил всё как есть. Если есть неуёмное желание оптимизировать, изучайте hal.dll/halmps.dll и ntoskrnl.exe/ntkrnlmp.exe и оптимизируйте на здоровье.
Для полноты картины, надо ещё добавить, что есть функция KeAcquireSpinLockRaiseToSynch, повышающая IRQL при захвате блокировки до CLOCK2_LEVEL (28).
Процедура DriverEntry
Теперь займемся собственно нашим фильтром. Как я уже говорил, это не-Pnp драйвер. Кода довольно много и я не буду приводить его полностью (см. архив к статье).
Код (Text):
На этот раз наш драйвер будет управлять уже двумя объектами: объектом "устройство-фильтр" (filter device object) и объектом "устройство управления" (control device object). Объект "устройство-фильтр" будет подключен к стеку клавиатуры, и через него будут проходить все IRP управляющие клавиатурой. Посредством объекта "устройство управления" программа управления будет отдавать драйверу необходимые команды: "подключить фильтр", "отключить фильтр", "передать перехваченные данные". На данный момент нам нужно только устройство управления. Этот объект будет именованным, для того чтобы программа управления могла получить к нему доступ. Мы не хотим работать одновременно с несколькими клиентами. Поэтому создадим эксклюзивный объект, определив TRUE в параметре Exclusive. В этом случае диспетчер объектов позволит создать только один описатель объекта. К сожалению, этот простой способ не очень надёжен, и открыть объект все же можно по относительному пути, т.е. открыв каталог "\Device" и передав его описатель в параметре RootDirectory макроса InitializeObjectAttributes. DDK вообще говорит, что параметр Exclusive зарезервирован. Поэтому мы добавим кое-какую дополнительную обработку запросов IRP_MJ_CREATE и IRP_MJ_CLOSE.
Код (Text):
Выделяем память под ассоциативный список и инициализируем его. Из этого списка мы будем выделять память под экземпляры нами же определенной структуры KEY_DATA_ENTRY.
Код (Text):
Экземпляры этой структуры будут хранить данные о перехваченных нажатиях/отпусканиях клавиш и их (экземпляры структуры) мы будем хранить в двусвязном списке. В седьмой части цикла - "Базовая техника: Работа с памятью. Использование ассоциативных списков" мы достаточно подробно разобрали как ассоциативный список (look-aside list), так и двусвязный список (doubly linked list). Уверен, что многие просто пропустили эту статью ;) Если это так, то придется её прочитать сейчас, т.к. я не буду повторяться, а без этого материала кое-что может быть не понятно. Единственная разница в том, что сейчас мы будем использовать неподкачиваемый ассоциативный список. Функции ExAllocateFromNPagedLookasideList и ExFreeToNPagedLookasideList для работы с неподкачиваемым ассоциативным списком реализованы в DDK как макросы, в отличие от именно функций для подкачиваемого ассоциативного списка. К сожалению, ввиду ограниченности макроязыка masm, мне пришлось реализовать их в виде функций _ExAllocateFromNPagedLookasideList и _ExFreeToNPagedLookasideList. Неподкачиваемый ассоциативный список нам потребовался, как вы догадываетесь, потому, что мы будем работать с ним на IRQL = DISPATCH_LEVEL.
Код (Text):
Глобальная переменная g_KeyDataListHead является головой двусвязного списка структур KEY_DATA_ENTRY.
Код (Text):
Спин-блокировка нам потребуется для организации монопольного доступа к списку структур KEY_DATA_ENTRY. Использовать объекты синхронизации, например, мьютекс, мы не можем, т.к. будем обращаться к списку на IRQL = DISPATCH_LEVEL.
Код (Text):
Эта спин-блокировка поможет нам организовать монопольный доступ к переменной g_pEventObject, в которой будет храниться указатель на объект событие. Этот объект будет использоваться для уведомления программы управления, о новых данных (Подробнее см. часть 14 "Базовая техника. Синхронизация: Использование объекта "событие" для взаимодействия драйвера с программой управления").
Код (Text):
С помощью этого мьютекса мы сможем монопольно выполнять некоторые участки кода.
Код (Text):
Заполняем все элементы массива указателей на процедуры диспетчеризации драйвера, адресом единственной процедуры DriverDispatch. Эта процедура будет распределять запросы между фильтром и устройством управления. Устройство управления будет получать от программы управления всего три запроса: IRP_MJ_CREATE, IRP_MJ_CLOSE и IRP_MJ_DEVICE_CONTROL. А вот устройство-фильтр может получить любой запрос, т.к. оно подключается в уже существующий стек, по которому могут циркулировать IRP любого типа. Зачастую, весь спектр IRP, проходящий по фильтруемому стеку вообще не известен. Фильтровать приходится только некоторые типы IRP, но если фильтр получит запрос, который его не интересует, он обязан направить его ниже по стеку. Именно поэтому мы должны заполнить весь массив MajorFunction. Иначе в незаполненных элементах останется указатель на системную функцию IopInvalidDeviceRequest, которая будет завершать IRP с кодом STATUS_INVALID_DEVICE_REQUEST, и мы блокируем продвижение таких запросов.
Процедура DriverDispatch
Через наш драйвер идут запросы к двум объектам: устройству управления и фильтру (если он подключен). Все IRP попадают в общую процедуру диспетчеризации DriverDispatch.
Код (Text):
Используя глобальные указатели g_pFilterDeviceObject и g_pControlDeviceObject, определяем, к какому объекту пришел запрос и, в зависимости от типа запроса вызываем соответствующую процедуру. Наше устройство управления обрабатывает только три типа запросов: IRP_MJ_CREATE, IRP_MJ_CLOSE и IRP_MJ_DEVICE_CONTROL. Но мы обязаны обработать все запросы к фильтру. Обработка будет заключаться в простой передаче IRP нижестоящему драйверу в процедуре FiDO_DispatchPassThrough. Запросы типа IRP_MJ_READ несут в себе коды клавиш, поэтому для этого типа запросов обработка будет особой. IRP типа IRP_MJ_POWER просто требует специфической обработки, поэтому и выделен в отдельную процедуру. Если мы, вдруг (чего быть не может), получили запрос для неизвестного нам устройства, завершаем его с кодом ошибки, т.к. не понятно, что ещё с этим IRP можно сделать.
Сначала разберем обработку запросов к устройству управления.
Процедура CDO_DispatchCreate
Код (Text):
Драйвер и программа управления построены таким образом, что программу управления можно выгрузить и загрузить повторно при уже запущенном драйвере и подключенном фильтре. Может так случиться, что список g_KeyDataListHead не пуст. Если вы внимательно проанализируете ход возможных событий после прочтения всей статьи, то станет ясно, что в списке может находиться одна структура KEY_DATA_ENTRY, соответствующая коду клавиши, нажатой сразу после некорректного завершения работы программы управления. Вышеприведенный цикл опустошает, возможно, непустой список g_KeyDataListHead.
Код (Text):
Если описатель объекта "устройство управления" уже открыт, не разрешаем повторное открытие. Это гарантирует нам наличие только одного клиента (остальные получат код STATUS_DEVICE_BUSY), а захват мьютекса гарантирует, что процедура CDO_DispatchClose в то же самое время не закроет описатель и не обнулит флаг g_fCDO_Opened.
Процедура CDO_DispatchClose
Код (Text):
Если клиент отключается, то и незачем следить за клавиатурой - FiDO_DispatchRead не должна больше устанавливать процедуру завершения.
Код (Text):
Если переменная g_pFilterDeviceObject пуста, то, очевидно, что нет и фильтра. Если к тому же у нас нет незавершенных IRP, завершение которых привело бы к вызову нашей процедуры завершения ReadComplete, находящейся в теле драйвера, то можно разрешить его выгрузить. Если фильтр всё ещё существует, драйвер остается невыгружаемым. Перед завершением работы программа управления просит драйвер отключить и удалить фильтр. Но возможны ситуации, когда драйвер не сможет этого сделать. Например, если кто-то подключен к стеку поверх нас, отключение фильтра "разорвет стек". Программа управления может просто забыть отключить фильтр или в ней может произойти исключение и описатель устройства автоматически закрывается системой. Речь, разумеется, не идет о нашей программе управления, в которой (я надеюсь) все сделано правильно. Имеется в виду программа управления вообще, т.е. общий принцип. Наконец, пользователь может завершать сеанс работы с системой, и все пользовательские процессы принудительно завершаются. В любом случае, как я уже сказал, драйвер и программа управления построены таким образом, что программу управления можно запустить повторно.
Код (Text):
Т.к. единственный наш клиент только что "ушел", сбрасываем флаг g_fCDO_Opened.
Процедура CDO_DispatchDeviceControl
Код (Text):
При получении от программы управления управляющего кода IOCTL_KEYBOARD_ATTACH, захватываем мьютекс и проверяем переданный нам описатель объекта "событие". Это мы уже делали в Process Monitor (см. часть 14). Если это действительно объект "событие", то у нас есть два варианта: либо мы должны создать фильтр и подключить его к стеку клавиатуры, либо фильтр уже существует и подключён.
Код (Text):
Если фильтр не подключен, будем считать, что он ещё не создан. Процедура KeyboardAttach сделает всё необходимое, вернув соответствующий код.
Код (Text):
Если подключение прошло успешно, запоминаем указатель на объект "событие" в глобальной переменной g_pEventObject и взводим флаги g_fFiDO_Attached и g_fSpy. Хотя фильтр уже подключен, блокировать доступ к переменной g_pEventObject, в данном случае, не требуется, т.к. флаг g_fSpy взводится после инициализации переменной g_pEventObject, а до тех пор процедура FiDO_DispatchRead не будет устанавливать процедуру завершения, а значит ReadComplete вообще не будет вызываться и g_pEventObject кроме нас никто трогать не будет.
Код (Text):
Если фильтр уже подключен, необходимо блокировать доступ к переменной g_pEventObject, т.к. к ней может обращаться наша процедура завершения ReadComplete. Спин-блокировка требуется из-за того, что ReadComplete работает на IRQL = DISPATCH_LEVEL.
Код (Text):
На всякий случай, если g_pEventObject содержит указатель на объект событие, уменьшаем счетчик ссылок и заносим туда указатель на новый объект событие. Тут требуется небольшое пояснение. На первый взгляд, этот код может показаться бессмысленным. Дело в том, что в предыдущих примерах, мы, для простоты, предполагали корректное поведение программы управления драйвером. Но, в идеале, драйвер должен быть непотопляем, даже если его собственная программа управления или кто-то другой выполнит какие-то непредсказуемые действия. В состав инструментов DDK для тестирования драйверов даже входит специальная утилита Device Path Exerciser (dc2.exe), которая, среди других тестов, шлет драйверу огромное количество управляющих кодов с заведомо неверными параметрами. Если программа управления дважды пошлет драйверу IOCTL_KEYBOARD_ATTACH, то, благодаря вышеприведенному коду, мы сможем корректно разобраться с двумя объектами "событие", а мьютекс g_mtxCDO_State избавит нас от множества потенциальных проблем.
Код (Text):
При получении от программы управления управляющего кода IOCTL_KEYBOARD_DETACH, пытаемся отключить фильтр, также под защитой мьютекса.
Код (Text):
Если фильтр подключен, сбрасываем флаг g_fSpy, чтобы FiDO_DispatchRead не устанавливала больше процедуру завершения, и пытаемся отключить и удалить фильтр.
Код (Text):
Если фильтр успешно отключен, сбрасываем соответствующий флаг. Если отключить фильтр не удалось, этот флаг останется во взведенном состоянии, что даст нам возможность при следующем (возможном) получении IOCTL_KEYBOARD_ATTACH, всё сделать корректно.
Код (Text):
Под защитой спин-блокировки, удаляем ссылку на объект "событие".
Код (Text):
При получении от программы управления управляющего кода IOCTL_GET_KEY_DATA, копируем в пользовательский буфер имеющиеся у нас к настоящему моменту структуры KEY_DATA. Процедуру FillKeyData, а также AddEntry и RemoveEntry я разбирать не буду, т.к. если вы читали седьмую часть цикла "Использование ассоциативных списков", их содержимое не должно представлять сложность, а подробности относительно структуры KEYBOARD_INPUT_DATA смотрите в DDK.
Процедура KeyboardAttach
Код (Text):
Если переменная g_pFilterDeviceObject не равна нулю, очевидно, она содержит указатель на объект "устройство-фильтр" и, наверное, он уже подключен к стеку.
Код (Text):
Если фильтра нет, создадим его.
Код (Text):
Объект "устройство-фильтр" должен быть безымянным, для того чтобы его нельзя было открыть напрямую по имени. Т.к. фильтр принадлежит стеку, но является привнесенным объектом, то явно не ему решать, разрешать ли открытие описателя или нет. Пусть с этим разбираются нижестоящие драйверы. На самом деле это не всегда верно. В случае со стеком клавиатуры, высокоуровневый драйвер фильтра Kbdclass имеет именованный объект "устройство-фильтр" KeyboardClassX и именно он обрабатывает запрос IRP_MJ_CREATE. Второй параметр функции IoCreateDevice определяет размер дополнительной области памяти объекта "устройство" (device extension), которая описывается гипотетической структурой DEVICE_EXTENSION. Гипотетической в том смысле, что такой структуры нет. Вы сами определяете, что необходимо поместить в дополнительную область памяти объекта "устройство" и сами определяете структуру. Device extension следует сразу за структурой DEVICE_OBJECT и инициализируется нулями. В нашем случае это структура FiDO_DEVICE_EXTENSION. Использование device extension позволяет драйверу создать сколь угодно много объектов "устройство" и хранить все относящиеся к ним данные в самих этих объектах.
Код (Text):
Надеюсь, вы помните, что функция IoGetAttachedDevice всегда возвращает указатель на объект "устройство", находящийся на вершине стека. Мы используем функцию IoGetDeviceObjectPointer для получения указателя на вершину стека по заранее известному нам имени одного из объектов "устройство", принадлежащего стеку. PnP драйверам, в этом смысле, проще, т.к. диспетчер PnP предоставляет им указатель на корневой объект стека - объект "физическое устройство". Т.е. я хочу сказать, что для подключения к стеку вам нужен указатель на любой объект стека. Как вы его получите, не имеет значения.
Код (Text):
Т.к. сейчас мы подключимся к стеку, то через нас могут пойти IRP. После установки флага g_fSpy мы будем устанавливать в них процедуру завершения. Когда эти IRP завершаться, мы не знаем, но знаем, что до этих пор драйвер нельзя выгружать, т.к. процедура завершения находится в теле драйвера. Поэтому проще всего просто сделать драйвер невыгружаемым.
Код (Text):
Сначала функция IoAttachDeviceToDeviceStack получает указатель на структуру DEVOBJ_EXTENSION (не путать с необязательной структурой DEVICE_EXTENSION). В поле ExtensionFlags этой структуры имеются кое-какие интересующие функцию IoAttachDeviceToDeviceStack флаги. Затем блокируется база данных диспетчера ввода/вывода и в pTopMostDeviceObject заносится указатель на объект "устройство", находящийся на вершине стека. Т.к. база данных диспетчера ввода/вывода блокирована, то состояние стека не изменится до снятия блокировки. Если объект "устройство" ещё не инициализирован или устройство или его драйвер отмечены для удаления или уже находится в состоянии удаления, функция IoAttachDeviceToDeviceStack отказывается прикреплять к стеку новый объект и возвращает NULL. В противном случае в поля AttachedDevice и AttachedTo объектов "устройство" заносятся соответствующие указатели (в этом и заключается процесс подключения к стеку нового объекта) и в подключенном объекте обновляются поля AlignmentRequirement, SectorSize и StackSize. AlignmentRequirement и SectorSize важны для устройств хранения, а StackSize необходимо увеличить на единицу в любом случае, т.к. глубина стека увеличилась на один объект (подробности см. в предыдущей статье). Обратите внимание на то, что подключение происходит не к объекту, указатель на который передан в параметре pTargetDevice, а к вершине стека кто бы на ней не находился. Если в промежутке между получением указателя на pTargetDevice и вызовом IoAttachDeviceToDeviceStack кто-то успеет подключить к стеку свой объект, pTargetDevice и возвращаемый pTopMostDeviceObject будут отличаться. В любом случае, возвращаемое из IoAttachDeviceToDeviceStack значение, в случае успеха, является указателем на объект "устройство", к которому был подключен фильтр. А фильтр теперь является вершиной стека и первым получает все IRP для этого стека предназначенные. В начале статьи мы выяснили, что поток необработанного ввода открывает один из объектов стека клавиатуры и, используя его описатель (точнее описатель объекта "файл", соответствующий объекту "устройство"), направляет ему запросы на чтение. Если IRP предназначаются какому-то устройству ниже по стеку, то каким образом они попадают в фильтр? Подсистема ввода/вывода ведет себя аналогично функциям IoGetAttachedDevice и IoAttachDeviceToDeviceStack, в том смысле, что в качестве адресата для IRP использует указатель на вершину стека. Вот, например, что делает функция ZwReadFile.
Код (Text):
Функция IoGetRelatedDeviceObject (исходный код см. в предыдущей статье) возвращает указатель на самый верхний объект "устройство" в стеке. Если же IRP формируется драйвером, так сказать вручную (см. исходный код процедуры QueryPnpDeviceState в предыдущей статье), то он будет послан напрямую целевому устройству и перехватить такой запрос с помощью фильтра невозможно, если конечно фильтр не находится ниже по стеку.
Код (Text):
Если IoAttachDeviceToDeviceStack подключила нас к стеку, заполняем структуру FiDO_DEVICE_EXTENSION. Туда мы помещаем указатель на объект, к которому мы подключились и указатель на объект "файл" ассоциированный с целевым объектом устройство (подробности см. в предыдущей статье). При отключении мы должны будем вызвать ObDereferenceObject по отношению к этому объекту "файл".
Код (Text):
Несколько флагов в нашем объекте фильтре придется обновить самостоятельно. Дело в том, что для диспетчера ввода/вывода наш объект должен выглядеть также как объект, к которому мы подключились. Например, флаг DO_BUFFERED_IO говорит диспетчеру ввода/вывода о том, что при операциях чтения/записи он должен копировать пользовательские буферы в системное адресное пространство, т.е. использовать метод ввода/вывода METHOD_BUFFERED. Флаги DO_DIRECT_IO и DO_BUFFERED_IO, естественно, взаимоисключающи. Хотя нам заранее известны флаги, которые использует устройство KeyboardClass0, а именно DO_BUFFERED_IO и DO_POWER_PAGABLE, мы используем более общий и универсальный механизм.
Код (Text):
Функция IoCreateDevice создает объект "устройство" с установленным флагом DO_DEVICE_INITIALIZING. До сих пор мы не касались этого момента потому, что создавали устройства только в процедуре DriverEntry. Дело в том, что по выходу из DriverEntry диспетчер ввода/вывода (в функции IopReadyDeviceObjects) сам сбрасывает этот флаг во всех объектах "устройство", созданных драйвером. Если же мы создаем устройство не в DriverEntry, придется сбросить флаг DO_DEVICE_INITIALIZING самостоятельно, иначе никто не сможет подключиться к неинициализированному объекту, как вы только что видели в коде IoAttachDeviceToDeviceStack. Также этот флаг проверяется при некоторых других операциях.
Процедура KeyboardDetach
Код (Text):
Перед тем как отключаться от стека, посмотрим, находимся ли мы на самой его вершине или к нам тоже уже кто-то подключился. Блокировать базу данных диспетчера ввода/вывода мы не можем, но зато можем предотвратить новые подключения, до тех пор, пока не проверим, есть ли кто-нибудь над нами.
Код (Text):
Здесь должно быть всё понятно.
Код (Text):
Если, возвращенный функцией IoGetAttachedDeviceReference, указатель не является указателем на наш фильтр, значит, к нам кто-то подключен. В этом случае отключаться от стека мы не будем и сбросим флаг DO_DEVICE_INITIALIZING. Если мы вызовем IoDetachDevice, то просто "разорвем стек", т.к. IoDetachDevice не делает каких бы то ни было проверок. Отключение объекта "устройство" от стека состоит в простом обнулении соответствующих указателей в связанных объектах.
Код (Text):
Отключив устройство от стека, IoDetachDevice проверяет, не ожидает ли оно удаления, а его драйвер выгрузки. И если это так и счетчик ссылок на объект равен нулю, инициирует отложенные операции.
Код (Text):
Если мы на вершине стека, уменьшаем счетчик ссылок на файловый объект, ассоциированный с объектом устройство, и отключаемся от стека. Восстанавливать флаг DO_DEVICE_INITIALIZING не имеет смысла, т.к. сейчас мы удалим фильтр.
Код (Text):
Удаляем объект "устройство-фильтр", но драйвер всё ещё остается невыгружаемым, т.к. мы можем иметь ожидающий завершения IRP, содержащий указатель на нашу процедуру завершения.
Код (Text):
Функция IoGetAttachedDeviceReference, в отличие от функции IoGetAttachedDevice, увеличивает счетчик ссылок в объекте, указатель на который возвращает. Это гарантирует, что объект не будет удален. Если мы были на вершине стека, то увеличили счетчик ссылок в нашем же объекте "устройство-фильтр" и IoDeleteDevice не сможет его удалить.
Код (Text):
Но IoDeleteDevice добавит флаг DOE_DELETE_PENDING, отметив тем самым, что объект "устройство" ожидает удаления. Когда мы вызовем ObDereferenceObject, счетчик ссылок станет равен 0, диспетчер объектов увидит, что объект должен быть удален и предпримет соответствующие шаги.
Теперь разберем процедуры обработки запросов к фильтру.
Процедура FiDO_DispatchPower
Код (Text):
IRP типа IRP_MJ_POWER обрабатываются отличным от всех остальных типов IRP способом.
Макрос IoCopyCurrentIrpStackLocationToNext мы подробно разобрали в прошлой статье (его мы будем использовать в процедуре FiDO_DispatchRead). Макрос IoSkipCurrentIrpStackLocation намного проще.
Код (Text):
Из прошлой статьи вы должны помнить, что функция IoCallDriver, перед тем как вызвать процедуру диспетчеризации драйвера, смещает текущий блок стека на одну позицию вниз.
Код (Text):
Если перед этим использовать макрос IoSkipCurrentIrpStackLocation, то получиться, что указатель блока стека вообще не изменится и нижестоящий драйвер получить тот же самый блок стека, что и драйвер вызвавший IoCallDriver (PoCallDriver). Вызов макроса IoSkipCurrentIrpStackLocation - это просто оптимизация. Действительно, если нам не нужно устанавливать процедуру завершения, то вызов макроса IoCopyCurrentIrpStackLocationToNext скопирует наш блок стека в блок стека нижестоящего драйвера (поля Control, CompletionRoutine и Context, как вы помните, не копируются). Т.о. нижестоящий драйвер всё равно получит те же самые параметры. Используя макрос IoSkipCurrentIrpStackLocation вместо IoCopyCurrentIrpStackLocationToNext, мы избегаем ненужной операции копирования блоков стека. Но, повторяю, это можно делать, только если не требуется устанавливать процедуру завершения, что должно быть и так понятно.
Процедура FiDO_DispatchPassThrough
Код (Text):
Здесь просто передаем IRP нижестоящему драйверу.
Процедура FiDO_DispatchRead
Код (Text):
Получив запрос типа IRP_MJ_READ адресованный фильтру, смотрим, взведен ли флаг g_fSpy. Если да, то мы должны установить процедуру завершения.
Код (Text):
Атомарно увеличиваем значение счетчика незавершенных запросов g_dwPendingRequests на единицу. Когда IRP будет завершаться, система вызовет нашу процедуру завершения ReadComplete, она прочитает код клавиши и уменьшит счетчик g_dwPendingRequests. "Атомарно" - означает, что только один поток даже на многопроцессорной машине сможет изменить значение переменной, а IRQL, на котором он выполняется, вообще не имеет значения. Даже если поток, выполняющийся на другом процессоре, попытается в то же самое время (на MP-машине в буквальном смысле) выполнить такой же код, он получит уже обновленное первым потоком значение. Это достигается за счет использования префикса lock. Увидев этот префикс, процессор блокирует шину данных на время выполнения инструкции. Другие процессоры не смогут в этот момент обратиться к этой области памяти и изменить её. Даже если эта область памяти кэшируется несколькими процессорами, в действие вступит механизм обеспечения когерентности кэша (processor's cache coherency mechanism) и кэши других процессоров будут объявлены недействительными, в результате чего процессоры должны будут повторно загрузить кеши уже обновленным содержимым памяти. Префикс lock может использоваться не со всеми инструкциями, а некоторые (например, xchg) всегда выполняются с этим префиксом. Подробнее см. "Intel Architecture Software Developer's Manual". Система (как ядро, так и режим пользователя) экспортирует целый набор Interlocked-функций, реализующих атомарный доступ, но мы можем использовать средства ассемблера.
Код (Text):
Устанавливаем процедуру завершения (детали см. в предыдущей статье). Когда IRP будет завершаться, мы сможем узнать код клавиши.
Код (Text):
Если флаг g_fSpy сброшен, процедура FiDO_DispatchRead ведет себя аналогично процедуре FiDO_DispatchPassThrough.
Код (Text):
Обратите внимание на то, что из всех процедур FiDO_XXX мы возвращаем код, который вернула функция IoCallDriver (PoCallDriver). Соответственно, DriverDispatch возвращает его в систему.
Процедура ReadComplete
Ну, и наконец, процедура ReadComplete, где собственно и происходят главные события, а именно получение кодов клавиш. Мы установили адрес этой процедуры в наш блок стека вызовом макроса IoSetCompletionRoutine. Когда IRP завершается, функция IoCompleteRequest последовательно вызывает все процедуры завершения. Этому и была посвящена практически вся предыдущая статья. IRP завершается в результате пост-обработки аппаратного прерывания (в нашем случае прерывания от контроллера клавиатуры), а значит в контексте случайного потока и на повышенном IRQL.
Код (Text):
Если IRP завершается с кодом успеха, то его буфер содержит, по крайней мере, одну структуру KEYBOARD_INPUT_DATA, несущую с собой вожделенный код клавиши.
Код (Text):
Поле Information содержит размер действительной части буфера и должно быть кратно размеру структуры KEYBOARD_INPUT_DATA.
Код (Text):
Перекладываем интересующие нас поля структуры KEYBOARD_INPUT_DATA в нашу структуру KEY_DATA_ENTRY и привязываем её к двусвязному списку g_KeyDataListHead. Это мы делаем в функции AddEntry и под защитой спин-блокировки g_KeyDataSpinLock. Блокировка списка нужна, как вы понимаете, для монопольного доступа к списку, а спин-блокировкой она должна быть потому, что процедура ReadComplete выполняется на IRQL = DISPATCH_LEVEL. DDK утверждает, что процедуры завершения могут быть вызваны на IRQL <= DISPATCH_LEVEL, но в данном случае мы всегда будем строго на IRQL = DISPATCH_LEVEL. Функция KeyboardClassServiceCallback драйвера Kbdclass, которая собственно и завершает IRP, использует KeAcquireSpinLockAtDpcLevel и KeReleaseSpinLockFromDpcLevel для блокировки.
Код (Text):
Но я всё равно использую макросы LOCK_ACQUIRE и LOCK_RELEASE (мне так больше нравится ;) ).
Код (Text):
Если у нас есть новые данные, сообщаем об этом программе управления, сигнализируя объект "событие". Здесь я также использую блокировку, для уверенности в том, что g_pEventObject всё ещё содержит действительный указатель.
Код (Text):
Поскольку мы возвращаем из процедуры завершения код отличный от STATUS_MORE_PROCESSING_REQUIRED, то должны следовать правилу №6 (см. часть 15).
Код (Text):
Запрос обработан - атомарно уменьшаем счетчик g_dwPendingRequests.
Код (Text):
Завершение IRP должно быть продолжено. Из материала предыдущей статьи вы должны помнить, что из процедур завершения можно возвращать либо STATUS_MORE_PROCESSING_REQUIRED, либо любой другой код. Код STATUS_SUCCESS использован для наглядности.
Программа управления
Код программы управления разберите сами. Ничего принципиально нового там нет. Поясню только несколько моментов. Во-первых, как известно, скорость набора текста примерно в 10 знаков в секунду является хорошим показателем. Так что максимально мы можем получать около 20 структур KEY_DATA в секунду, и в то же самое время до клавиатуры могут очень долго не дотрагиваться. Поэтому для исключения лишних запросов к драйверу мы забираем накопившуюся информацию не чаше чем раз в секунду. А если забирать нечего, то и вовсе ничего не запрашиваем. Такая логика работы достигается за счет усыпления потока на некоторое время и ожидания события, которое сигнализирует драйвер. Во-вторых, т.к. 20 структур KEY_DATA - это намного меньше, чем одна страница, мы используем буферизованный ввод/вывод и забираем информацию через DeviceIoControl. Если требуется обмен бОльшими объемами (скажем, ориентировочно, несколько страниц), то лучше использовать метод METHOD_NEITHER, а вместо DeviceIoControl - ReadFile. В-третьих, пользователь может закрыть программу управления либо с помощью мыши, либо с помощью клавиатуры. Если он использует мышь, то драйвер не будет выгружен, т.к. последний прошедший через драйвер IRP содержит указатель на нашу процедуру завершения и находится сейчас в очереди драйвера Kbdclass. Чтобы программа управления имела возможность выгрузить драйвер, пользователь должен нажать на клавишу. Поэтому, выводя соответствующее сообщение, мы даем пользователю необходимые инструкции. И наконец, про обещанную отмену IRP. Если бы можно было отменить этот злосчастный ожидающий завершения IRP, то нам не пришлось бы пугать пользователя странными сообщениями. Мы бы просто отменили этот запрос и выгрузили бы драйвер. И такой механизм существует. Драйвер Kbdclass поддерживает отмену только одного типа IRP и это как раз IRP_MJ_READ. Проблема в том, что отменить IRP, находящийся в очереди другого драйвера не так то просто. В своей книге "Programming The Windows Driver Model" 2nd Edition Вальтер Они приводит пару способов отмены чужих IRP. Первый их них точно не подойдет, а вот второй… Если не подойдет и второй, то остается только организовать свою собственную очередь и помещать туда все пришедшие IRP типа IRP_MJ_READ, а нижестоящему драйверу слать их дубликаты. Завершения дублированных IRP перехватывать, извлекать из очереди их оригиналы и перекладывать в них необходимые данные. Если у фильтра будет своя очередь, то отмена IRP становится делом техники. Насколько этот сценарий возможен практически, я не знаю, т.к. при его реализации могут возникнуть непредвиденные сложности.
Ну, и самое последнее. В архиве вы обнаружите сразу два фильтра. Второй - MouSpy, получен путем замены слов "keyboard", "kbd" и т.п. в прародителе на их "мышиные" аналоги. Ну и конечно я не смог удержаться и добавил ещё кое-что. Поэтому этот фильтр не просто пассивно следит за "мышиными" событиями, но может вносить в них некоторые коррективы. Но, если у вас клавиатура/мышь USB, то подключить фильтры, скорее всего, не удастся. Во всяком случае, подключить фильтр к стеку для USB-мыши мне не удалось, а USB-клавиатуры у меня нет. Причина в том, что внутренне функция IoGetDeviceObjectPointer вызывает функцию ZwOpenFile, а она, в свою очередь, формирует запрос IRP_MJ_CREATE и шлет его в стек (см. предыдущую статью). Вот три стека мыши на одной из моих машин: первый для классической PS/2 мыши, второй для терминальной сессии и третий для мыши USB.
Код (Text):
Видимо, один из драйверов в стеке (скорее всего mouhid) отказывается обработать запрос IRP_MJ_CREATE, возвращая код STATUS_SHARING_VIOLATION, т.е. совместный доступ к файлу запрещен (имеется в виду объект "файл" ассоциированный с объектом "устройство"). Как бы там ни было, в дальнейшие детали я не вдавался. Не удаётся подключиться к USB стеку… и слава богу, ибо "со свиным рылом, да в калашный ряд?"… Как мы будем обрабатывать IRP_MN_QUERY_REMOVE_DEVICE, IRP_MN_REMOVE_DEVICE и IRP_MN_SURPRISE_REMOVAL, в случае если пользователь отключит/выдернет клавиатуру/мышку из USB-порта? Так что, доставайте из чулана своих старых боевых подруг или ждите следующую статью (если я её когда-нибудь напишу ;) ).
Рис. 16-1. KbdSpy и MouSpy в действии.
Исходный код драйвера в архиве.
© Four-F
Драйверы режима ядра: Часть 16 : Драйвер-фильтр (не PnP)
Дата публикации 12 янв 2005
