Драйверы режима ядра: Часть 5: Полнофункциональный драйвер — Архив WASM.RU

Все статьи

Драйверы режима ядра: Часть 5: Полнофункциональный драйвер — Архив WASM.RU

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


 ;@echo off
 ;goto make

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;
 ; VirtToPhys - Драйвер режима ядра
 ;
 ;  Переводит виртуальный адрес в физический
 ;
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 .386
 .model flat, stdcall
 option casemap:none

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;                              В К Л Ю Ч А Е М Ы Е    Ф А Й Л Ы                                     
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 include \masm32\include\w2k\ntstatus.inc
 include \masm32\include\w2k\ntddk.inc
 include \masm32\include\w2k\ntoskrnl.inc
 include \masm32\include\w2k\w2kundoc.inc

 includelib \masm32\lib\w2k\ntoskrnl.lib

 include \masm32\Macros\Strings.mac

 include ..\common.inc

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;                             Н Е И З М Е Н Я Е М Ы Е    Д А Н Н Ы Е                                
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 .const
 CCOUNTED_UNICODE_STRING    "\\Device\\devVirtToPhys", g_usDeviceName, 4
 CCOUNTED_UNICODE_STRING    "\\??\\slVirtToPhys", g_usSymbolicLinkName, 4

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;                                              К О Д                                                
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 .code

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;                                    GetPhysicalAddress                                             
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 GetPhysicalAddress proc dwAddress:DWORD

     mov eax, dwAddress
     mov ecx, eax

     shr eax, 22
     shl eax, 2

     mov eax, [0C0300000h][eax]

     .if ( eax & (mask pde4kValid) )
         .if !( eax & (mask pde4kLargePage) )
             mov eax, ecx
             shr eax, 10
             and eax, 1111111111111111111100y
             add eax, 0C0000000h
             mov eax, [eax]

             .if eax & (mask pteValid)
                 and eax, mask ptePageFrameNumber

                 and ecx, 00000000000000000000111111111111y
                 add eax, ecx
             .else
                 xor eax, eax
             .endif
         .else
             and eax, mask pde4mPageFrameNumber
             and ecx, 00000000001111111111111111111111y
             add eax, ecx
         .endif
     .else
         xor eax, eax
     .endif

     ret

 GetPhysicalAddress endp

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;                                   DispatchCreateClose                                             
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 DispatchCreateClose proc pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP

     mov eax, pIrp
     assume eax:ptr _IRP
     mov [eax].IoStatus.Status, STATUS_SUCCESS
     and [eax].IoStatus.Information, 0
     assume eax:nothing

     fastcall IofCompleteRequest, pIrp, IO_NO_INCREMENT

     mov eax, STATUS_SUCCESS
     ret

 DispatchCreateClose endp

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;                                     DispatchControl                                               
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 DispatchControl proc uses esi edi ebx pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP

 local status:NTSTATUS
 local dwBytesReturned:DWORD

     and dwBytesReturned, 0

     mov esi, pIrp
     assume esi:ptr _IRP

     IoGetCurrentIrpStackLocation esi
     mov edi, eax
     assume edi:ptr IO_STACK_LOCATION

     .if [edi].Parameters.DeviceIoControl.IoControlCode == IOCTL_GET_PHYS_ADDRESS
         .if ( [edi].Parameters.DeviceIoControl.OutputBufferLength >= DATA_SIZE ) && ( [edi].Parameters.DeviceIoControl.InputBufferLength >= DATA_SIZE )

             mov edi, [esi].AssociatedIrp.SystemBuffer
             assume edi:ptr DWORD

             xor ebx, ebx
             .while ebx < NUM_DATA_ENTRY

                 invoke GetPhysicalAddress, [edi][ebx*(sizeof DWORD)]

                 mov [edi][ebx*(sizeof DWORD)], eax
                 inc ebx
             .endw

             mov dwBytesReturned, DATA_SIZE
             mov status, STATUS_SUCCESS
         .else
             mov status, STATUS_BUFFER_TOO_SMALL
         .endif
     .else
         mov status, STATUS_INVALID_DEVICE_REQUEST
     .endif

     assume edi:nothing

     m2m [esi].IoStatus.Status, status
     m2m [esi].IoStatus.Information, dwBytesReturned

     assume esi:nothing

     fastcall IofCompleteRequest, pIrp, IO_NO_INCREMENT

     mov eax, status
     ret

 DispatchControl endp

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;                                       DriverUnload                                                
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 DriverUnload proc pDriverObject:PDRIVER_OBJECT

         invoke IoDeleteSymbolicLink, addr g_usSymbolicLinkName

         mov eax, pDriverObject
         invoke IoDeleteDevice, (DRIVER_OBJECT PTR [eax]).DeviceObject

     ret

 DriverUnload endp

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;               В Ы Г Р У Ж А Е М Ы Й   П Р И   Н Е О Б Х О Д И М О С Т И   К О Д                   
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 .code INIT

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;                                       DriverEntry                                                 
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 DriverEntry proc pDriverObject:PDRIVER_OBJECT, pusRegistryPath:PUNICODE_STRING

 local status:NTSTATUS
 local pDeviceObject:PVOID

     mov status, STATUS_DEVICE_CONFIGURATION_ERROR

     invoke IoCreateDevice, pDriverObject, 0, addr g_usDeviceName, FILE_DEVICE_UNKNOWN, \
                                              0, FALSE, addr pDeviceObject

     .if eax == STATUS_SUCCESS
         invoke IoCreateSymbolicLink, addr g_usSymbolicLinkName, addr g_usDeviceName
         .if eax == STATUS_SUCCESS
             mov eax, pDriverObject
             assume eax:PTR DRIVER_OBJECT
             mov [eax].MajorFunction[IRP_MJ_CREATE*(sizeof PVOID)],           offset DispatchCreateClose
             mov [eax].MajorFunction[IRP_MJ_CLOSE*(sizeof PVOID)],            offset DispatchCreateClose
             mov [eax].MajorFunction[IRP_MJ_DEVICE_CONTROL*(sizeof PVOID)],   offset DispatchControl
             mov [eax].DriverUnload,                                          offset DriverUnload
             assume eax:nothing
             mov status, STATUS_SUCCESS
         .else
             invoke IoDeleteDevice, pDeviceObject
         .endif
     .endif

     mov eax, status
     ret

 DriverEntry endp

 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ;                                                                                                   
 ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 end DriverEntry

 :make

 set drv=VirtToPhys

 \masm32\bin\ml /nologo /c /coff %drv%.bat
 \masm32\bin\link /nologo /driver /base:0x10000 /align:32 /out:%drv%.sys /subsystem:native /ignore:4078 %drv%.obj rsrc.obj

 del %drv%.obj
 move %drv%.sys ..

 echo.
 pause




Имя устройства и символьной ссылки

Начнем с определения структур UNICODE_STRING, описывающих имя устройства и символьной ссылки. Как я уже говорил в третьей части, ядро любит работать со строками именно в этом формате.

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


 .const
 uszDeviceName          dw "\", "D", "e", "v", "i", "c", "e", "\", "D", "e", "v", "N", "a", "m", "e", 0
 uszSymbolicLinkName    dw "\", "?", "?", "\", "D", "e", "v", "N", "a", "m", "e", 0

 .code
 DriverEntry proc . . .
 . . .
 local usDeviceName:UNICODE_STRING
 local usSymbolicLinkName:UNICODE_STRING
 . . .
     invoke RtlInitUnicodeString, addr usDeviceName, offset uszDeviceName
     invoke RtlInitUnicodeString, addr usSymbolicLinkName, offset uszSymbolicLinkName

Задача функции RtlInitUnicodeString измерить unicode-строку и заполнить структуру UNICODE_STRING (см. Часть 3). Т.к. сами unicode-строки в этом коде определены статически, т.е. никогда не меняются, то можно, еще на этапе компиляции, заполнить структуру UNICODE_STRING. Это проще, нагляднее и требует меньшего количества байт (8 байт на структуру UNICODE_STRING + максимум 3 байта на выравнивание. Против минимум 14 байт на вызов функции RtlInitUnicodeString + временные издержки). Именно так и поступим, а макрос CCOUNTED_UNICODE_STRING еще больше облегчит нам жизнь, и весь вышеприведенный код (мы добавим еще выравнивание) превратится в две элегантные строки.


 CCOUNTED_UNICODE_STRING "\\Device\\DevName", usDeviceName,       4
 CCOUNTED_UNICODE_STRING "\\??\\DevName",     usSymbolicLinkName, 4

Не знаю как вам, а мне этот вариант правится значительно больше. Функция же RtlInitUnicodeString требуется когда длина строки заранее неизвестна. В ntoskrnl.exe, кстати, имеется целый набор функций, как для заполнения структур *_STRING, так и для работы со строками вообще.


 .const
 CCOUNTED_UNICODE_STRING    "\\Device\\devVirtToPhys", g_usDeviceName, 4
 CCOUNTED_UNICODE_STRING    "\\??\\slVirtToPhys", g_usSymbolicLinkName, 4

Таким образом, мы имеем две глобальные переменные g_usDeviceName и g_usSymbolicLinkName типа UNICODE_STRING с именем устройства и именем символьной ссылки соответственно. Как я уже говорил в прошлый раз, префиксы "dev" и "sl" я добавил только для наглядности.

На более ранних выпусках Windows NT в пространстве имен диспетчера объектов отсутствует каталог "\??". В этом случае надо заменить в имени символьной ссылки "\??" на "\DosDevices". Причем, в более поздних выпусках это тоже будет работать, т.к. для совместимости в корневом каталоге пространства имен диспетчера объектов имеется символьная ссылка "\DosDevices", значением которой является строка "\??"


Процедура инициализации драйвера

Кое-что о процедуре DriverEntry мы уже узнали в третьей части статьи. Прежде чем мы пойдем дальше, обратите внимание на строку:


 .code INIT

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

Поскольку, процедура DriverEntry просто крошечная, и весь остальной код и данные тоже занимают очень мало места, а в параметре компоновщика /align:32 мы определили выравнивание секций по границе 32 байта, то весь драйвер, со всеми своими потрохами, умещается всего на одной странице памяти (4кБ). А как известно, минимальной единицей выделения памяти, на данный момент, является страница. Т.е. можно было и не использовать отдельную секцию, т.к. в данном случае это ничего не дает. В драйверах для более ранних выпусков Windows NT процедура DriverEntry занимала довольно приличное место, поэтому собственно Microsoft так и поступила.


     mov status, STATUS_DEVICE_CONFIGURATION_ERROR

Прежположим, что во время инициализации драйвера произойдет ошибка. Если это случится, то это значение и вернется системе, и на стороне режима пользователя вызов функции StartService завершится ошибкой.


     invoke IoCreateDevice, pDriverObject, 0, addr g_usDeviceName, FILE_DEVICE_UNKNOWN, \
                                              0, FALSE, addr pDeviceObject

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


 IoCreateDevice proto std call DriverObject:PDRIVER_OBJECT, DeviceExtensionSize:DWORD, \
                               DeviceName:PUNICODE_STRING,  DeviceType:DEVICE_TYPE, \
                               DeviceCharacteristics:DWORD, Exclusive:BOOL, \
                               DeviceObject: PDEVICE_OBJECT

DriverObject

- указатель на объект "драйвер" (структура DRIVER_OBJECT), созданный системой;

DeviceExtensionSize

- произвольный размер области дополнительной памяти устройства (device extension), которую можно выделить в каждом объекте "устройство".

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

DeviceName

- необязательный указатель на имя устройства в формате UNICODE_STRING.

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

DeviceType

- определяет уникальный идентификатор типа устройства.

Этого момента мы коснулись в прошлый раз, при описании управляющего кода ввода-вывода. У нас этот параметр всегда будет FILE_DEVICE_UNKNOWN;

DeviceCharacteristics

- дополнительная информация об устройстве.

У нас ничего такого нет, поэтому ставим в 0;

Exclusive

- определяет монопольный доступ к устройству.

Опять же в прошлый раз, при описании функции CreateFile, я говорил, что мне не удалось получить монопольный доступ к устройству используя параметр dwShareMode. Это можно сделать с помощью Exclusive. Трудно сказать нужно нам это или нет, поэтому, мы разрешаем одновременное использование устройства несколькими приложениями устанавливая этот параметр в FALSE;

DeviceObject

- этот параметр является возвращаемым и будет указывать, при успешном завершении функции IoCreateDevice, на высокопарно называемый Microsoft объект "устройство", являющийся на самом деле структурой DEVICE_OBJECT. Через эту структуру система и будет им управлять.

Если создать символьную ссылку не удастся, то указатель на объект "устройство" потребуется для его удаления. Поэтому, мы передаем в этом параметре адрес локальной переменной pDeviceObject. Можно сохранить указатель на объект "устройство" и в глобальной переменной и использовать его в процедуре выгрузки драйвера, но я этого делать не стал, чтобы не создавать лишнюю секцию ?data. А при выгрузке драйвера мы извлечем этот указатель прямо из объекта "драйвер".


     .if eax == STATUS_SUCCESS
         invoke IoCreateSymbolicLink, addr g_usSymbolicLinkName, addr g_usDeviceName

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


         .if eax == STATUS_SUCCESS
             mov eax, pDriverObject
             assume eax:ptr DRIVER_OBJECT
             mov [eax].MajorFunction[IRP_MJ_CREATE*(sizeof PVOID)],           offset DispatchCreateClose
             mov [eax].MajorFunction[IRP_MJ_CLOSE*(sizeof PVOID)],            offset DispatchCreateClose
             mov [eax].MajorFunction[IRP_MJ_DEVICE_CONTROL*(sizeof PVOID)],   offset DispatchControl

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

В состав структуры DRIVER_OBJECT входит массив MajorFunction. В этот масив помещаются указатели на процедуры диспетчеризации (dispatch routines), предназначенные для обработки разных типов пакетов запроса ввода-вывода (IRP). Каждый элемент этого массива соответствует своему типу IRP. Если, например, драйверу необходимо обрабатывать запрос типа IRP_MJ_SHUTDOWN, уведомляющий о завершении работы системы, то он должен поместить в соответствующую позицию массива MajorFunction указатель на функцию, которой запросы этого типа и будут направляться. Если такая функциональность драйверу не нужна, как в нашем случае, то и заполнять этот элемент массива MajorFunction не требуется. Т.о. мы совсем не обязаны заполнять все элементы массива MajorFunction, коих в Windows 2000 DDK определено аж целых 28 штук (IRP_MJ_MAXIMUM_FUNCTION+1). Все зависит от задач стоящих перед драйвером. Например, драйвер beeper.sys и так прекрасно справлялся со своей работой, вообще не устанавливая никаких процедур диспетчеризации. В элементы массива MajorFunction не заполненные драйвером диспетчер ввода-вывода заносит указатель на внутреннюю функцию IopInvalidDeviceRequest. Эта функция уведомляет о попытке обращения к неподдерживаемой данным драйвером функции.

Для того, чтобы код режима пользователя смог успешно вызывать функции CreateFile, DeviceIoControl и CloseHandle, мы должны обрабатывать как минимум три типа запросов:

IRP_MJ_CREATE

- формируется диспетчером ввода-вывода при вызове кодом режима пользователя функции CreateFile;

IRP_MJ_DEVICE_CONTROL

- формируется диспетчером ввода-вывода при вызове кодом режима пользователя функции DeviceIoControl;

IRP_MJ_CLOSE

- формируется диспетчером ввода-вывода при вызове кодом режима пользователя функции CloseHandle.

Запросы типов IRP_MJ_CREATE и IRP_MJ_CLOSE будет обрабатывать одна функция DispatchCreateClose. Почему узнаем позже.

В ntddk.inc, среди прочих, определены константы могущие представлять для нас интерес:


 IRP_MJ_CREATE               equ 0
 . . .
 IRP_MJ_CLOSE                equ 2
 IRP_MJ_READ                 equ 3
 IRP_MJ_WRITE                equ 4
 . . .
 IRP_MJ_DEVICE_CONTROL       equ 0Eh
 . . .
 IRP_MJ_CLEANUP              equ 12h

Это порядковые номера, определяющие положение указателя на процедуру диспетчеризации в массиве MajorFunction. Умножив соответствующую константу на размер указателя, равный 4 байтам, мы получим смещение в массиве MajorFunction, по которому должен быть расположен указатель на соответствующую процедуру диспетчеризации.


             mov [eax].DriverUnload,                                          offset DriverUnload

Еще одно ключевое поле структуры DRIVER_OBJECT DriverUnload. Туда мы должны поместить, если хотим иметь возможность динамически выгружать драйвер, указатель на процедуру, которую система будет вызывать при обращении кода режима пользователя к функции ControlService с параметром SERVICE_CONTROL_STOP.

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


             assume eax:nothing
             mov status, STATUS_SUCCESS

Если мы благополучно дошли до этой точки, то инициализация драйвера прошла успешно, о чем мы и сообщаем системе, возвращая код успеха STATUS_SUCCESS.


         .else
             invoke IoDeleteDevice, pDeviceObject
         .endif
     .endif

Если же создать символьную ссылку не удалось, то мы должны удалить объект "устройство", созданный на предыдущем этапе функцией IoCreateDevice, чтобы привести систему в прежнее состояние. Именно должны! Это вам не режим пользователя, где после завершения процесса все объекты ему принадлежащие автоматически уничтожаются системой. В режиме ядра никто за нас делать грязную работу не будет. Это общее правило. Выделили память - освободите. Создали объект - удалите. Получили ссылку на объект - "отдайте" назад. И т.д. и т.п. Запомните это.


     mov eax, status
     ret

Возвращаем системе текущий код состояния. Если это STATUS_SUCCESS, то драйвер остается в памяти и диспетчер ввода-вывода будет формировать и направлять его устройствам пакеты запроса ввода-вывода. Если это какое-либо другое значение, то драйвер удаляется.

Таким образом, после удачного завершения DriverEntry в системе появится три новых объекта:

Объект "драйвер", представляющий отдельный драйвер в системе.

Из этого объекта (точнее из массива MajorFunction структуры DRIVER_OBJECT) диспетчер ввода-вывода получает адреса процедур диспетчеризации;

Объект "устройство", представляющий в системе устройство.

Из этого объекта (точнее из поля DriverObject структуры DEVICE_OBJECT) диспетчер ввода-вывода получает указатель на объект "драйвер" это устройство обслуживающий;

Объект "файл", представляющий для кода режима пользователя объект "устройство".

Из этого объекта (точнее из поля DeviceObject структуры FILE_OBJECT) диспетчер ввода-вывода получает указатель на объект "устройство";

Этот объект прозрачен для нас. О том, как объект "файл" возникает, мы говорили в прошлый раз;

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

Используется диспетчером объектов для трансляции во внутреннее имя устройства.

На рис. 5-1 показаны основные взаимосвязи этих объектов. Эта схема поможет вам глубже понять дальнейший материал.

Рис. 5-1. Взаимосвязи объектов "файл", "устройство" и "драйвер" с пакетом запроса ввода-вывода, и кодом драйвера




Процедуры диспетчеризации запросов ввода-вывода

Все процедуры диспетчеризации имеют одинаковый прототип.


 DispatchRoutine proto stdcall pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP

pDeviceObject

- указатель на объект "устройство" (структура DEVICE_OBJECT).

Если драйвер обслуживает несколько устройств, то по значению этого параметра можно определить, к какому именно устройству пришел запрос. Или обратиться к области дополнительной памяти устройства. В нашем случае, в процедурах диспетчеризации, использовать указатель на объект "устройство" не требуется;

pIrp

- указатель на текущий пакет запроса ввода-вывода (структура _IRP).

Диспетчер ввода-вывода создает IRP, представляющий операцию ввода-вывода. Через параметр pIrp драйверу передается указатель на IRP. Получив IRP, драйвер выполняет указанную в пакете операцию и возвращает его диспетчеру ввода-вывода, чтобы тот, либо завершил эту операцию, либо передал пакет другому драйверу для дальнейшей обработки. Завершать IRP или передавать его дальше решает сам драйвер. Наш драйвер одноуровневый, поэтому никакой дальнейшей обработки не требуется. По завершении операции ввода-вывода, результаты возвратятся коду режима пользователя, а IRP будет удален.

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


Процедура обработки IRP типов IRP_MJ_CREATE и IRP_MJ_CLOSE

Для начала о том, почему процедура DispatchCreateClose обрабатывает у нас запросы такого разного типа. Запросы типов IRP_MJ_CREATE и IRP_MJ_CLOSE направляются драйверу, когда код режима пользователя вызывает функции CreateFile и CloseHandle, соответственно. Единственное, что нам надо сделать для обработки обоих запросов, это заполнить блок статуса ввода-вывода (I/O status block) - вложенную в _IRP структуру IO_STATUS_BLOCK - и вернуть код успеха. Поэтому, чтобы не плодить лишние процедуры-близнецы, я их и объединил.

Если же предполагается, при обработке запроса типа IRP_MJ_CREATE, выделять дополнительную память, инициализировать какие-либо переменные и .т.п, то при закрытии описателя устройства, т.е. при вызове кодом режима пользователя CloseHandle, эти структуры придется удалять. Т.е. действия драйвера при получении пакетов IRP_MJ_CREATE и IRP_MJ_CLOSE будут отличаться. В этом случае, естественно, процедуры обработки следует разделить.


 DispatchCreateClose proc pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP

     mov eax, pIrp
     assume eax:ptr _IRP
     mov [eax].IoStatus.Status, STATUS_SUCCESS
     and [eax].IoStatus.Information, 0
     assume eax:nothing

Заполняем блок статуса ввода-вывода, определяющего состояние запроса ввода-вывода.

Значение поля Status определяет, как завершится на стороне режима пользователя вызов функций CreateFile и CloseHandle. Мы хотим, чтобы пользовательский процесс открывал и закрывал описатель устройства без ошибок. Поэтому, помещаем в поле Status код успеха STATUS_SUCCESS.

Смысл поля Information зависит от типа запроса. Это может быть значение количества байт переданных в пользовательское приложение или указатель на структуру. В данном случае мы поместим в это поле 0. При обработке запроса типа IRP_MJ_DEVICE_CONTROL (в процедуре DispatchControl), мы должны будем поместить туда количество байт, которое необходимо скопировать в пользовательский буфер.


     fastcall IofCompleteRequest, pIrp, IO_NO_INCREMENT

     mov eax, STATUS_SUCCESS
     ret

 DispatchCreateClose endp

Вызов функции IofCompleteRequest инициирует операцию завершения ввода-вывода (I/O completion).

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

Если драйвер обслуживает физическое устройство, то операция ввода-вывода может длиться ощутимое время. Пока поток ждет завершения операции, система не предоставляет ему процессорное время (при синхронных операциях ввода-вывода, как в нашем случае). После окончания операции ожидавший поток вправе немедленно возобновить выполнение и обработать полученные данные. Именно через второй параметр функции IofCompleteRequest драйвер и сообщает на какую величину повысить приоритет ожидавшего потока. Для устройств "тугодумов" предусмотрены бОльшие значения повышения приоритета. Например, для звуковых карт DDK рекомендует использовать константу IO_SOUND_INCREMENT, равную 8.

В нашем случае, повышения приоритета потока не требуется, и мы передаем IO_NO_INCREMENT равную нулю.

Функция IofCompleteRequest является fastcall-функцией (см. ниже). В префиксе имени функции присутствует символ 'f'. Существует, кстати сказать, и stdcall вариант IoCompleteRequest. Обратите внимание на отсутствие символа 'f' в префиксе. Но, в образовательных целях, мы будем использовать быструю версию. Эта не единственная fastcall-функция - есть и другие. И у них также есть свои stdcall аналоги, которые, как правило, являются оболочками вокруг соответствующих fastcall-функций.


Соглашение о передаче параметров

В функциях API ядра Windows NT используется три типа соглашений о передаче параметров (calling convention): stdcall, cdecl и fastcall. Последний тип не поддерживается компилятором masm.

Такие функции принимают первый аргумент в регистре ecx, второй в edx, остальные, при наличии таковых, помещаются в стек в обратном порядке (справа налево). Стек очищает вызванная функция.

Декорированные имена функций fastcall начинаются с символа "@", после имени добавляется символ "@" с десятичным числом, обозначающим суммарный размер аргументов в байтах. Например, функция IofCompleteRequest декорируется следующим образом:


 @IofCompleteRequest@8

Это значит, что это fastcall-функция, экспортируемое имя IofCompleteRequest, принимает два аргумента размером DWORD каждый.

В файле \include\w2k\ntoskrnl.inc она определена следующим образом (на ключевое слово SYSCALL можете не обращать внимание):


 EXTERNDEF SYSCALL @IofCompleteRequest@8:PROC
 IofCompleteRequest TEXTEQU <@IofCompleteRequest@8>

Для упрощения вызова таких функций я написал макрос fastcall:


 fastcall MACRO api:REQ, p1, p2, px:VARARG

 local arg

     ifnb <px>
         % for arg, @ArgRev( <px> )
             push arg
         endm
     endif

     ifnb <p1>

         ifdifi <p1>, <ecx>
             mov ecx, p1
         endif

         ifnb <p2>
             ifdifi <p2>, <edx>
                 mov edx, p2
             endif
         endif

     endif

     call api

 ENDM

Здесь, для экономии места, я привожу упрощенную версию этого макроса. Чтобы не плодить лишние файлы с макросами, мне пришлось поместить этот макрос в \include\w2k\ntddk.inc, где и можно посмотреть полный вариант. В оригинальном ntddk.h такого макроса, естественно, нет.


Виды управления буферами при обработке IRP

Напоследок, хочу еще немножко помучить вас теорией ;-)

Диспетчер ввода-вывода поддерживает три вида управления буферами:

  • буферизованный ввод-вывод (buffered I/O);
  • прямой ввод-вывод (direct I/O);
  • ввод-вывод без управления (neither I/O).

Этого момента мы чуть-чуть касались в прошлой статье. Теперь поговорим более обстоятельно. Здесь, мы будем рассматривать только случай применения функции DeviceIoControl для организации ввода-вывода. Использование ReadFile и WriteFile не рассматриваются. Пример использования ReadFile смотрите в \src\Article4-5\NtBuild.


буферизованный ввод-вывод

Именно этот вид управления используется в драйвере VirtToPhys.

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

Создавая IRP, при операции записи, диспетчер ввода-вывода копирует данные из пользовательского входного буфера в выделенный системный буфер и передает драйверу его адрес в поле AssociatedIrp.SystemBuffer структуры _IRP. Размер скопированных данных помещается в поле Parameters.DeviceIoControl.InputBufferLength структуры IO_STACK_LOCATION (на эту структуру указывает поле Tail.Overlay.CurrentStackLocation структуры _IRP, значение которого можно получить используя макрос IoGetCurrentIrpStackLocation).

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

Завершая IRP, при операции чтения, диспетчер ввода-вывода копирует данные из системного буфера в пользовательский выходной буфер. Размер копируемых данных извлекается из поля IoStatus.Information структуры _IRP. Это поле должен заполнить драйвет - только он знает сколько байт поместил в системный буфер.

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

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

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

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

Таким образом, этот вид управления буферами следует использовать при относительно небольших размерах буферов. Или если опереция ввода-вывода выполняется не часто.

Если же драйверу приходиться перегонять большие порции данных, например, потоки аудио или видео данных (эта статья даже вскользь не касается этой темы), то следует использовать более эффективный метод.


прямой ввод-вывод

Используется для организации прямого доступа к памяти (direct memory access, DMA).

Я не буду подробно рассматривать этот вид управления, т.к. в контексте данных статей ему нет применения.

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

Диспетчер ввода-вывода блокирует выходной буфер в памяти, делая его неподкачиваемым, и создает MDL (Memory Descriptor List), описывающий физические страницы занимаемые буфером. Указатель на MDL помещается в поле MdlAddress структуры _IRP. Подробнее см. DDK.

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


ввод-вывод без управления

Диспетчер ввода-вывода помещает в поле DeviceIoControl.Type3InputBuffer структуры IO_STACK_LOCATION указатель на пользовательский входной буфер, а в поле UserBuffer структуры _IRP указатель на пользовательский выходной буфер и оставляет драйверу возможность управлять ими самостоятельно. Т.о. вся ответственность за управление пользовательскими буферами ложится на драйвер. Он может блокировать их в памяти, отображать на системное адресное пространство или обращаться к ним напрямую и т.д.

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

Поскольку, мы всегда (в рассмотренных драйверах) выполняемся при IRQL = PASSIVE_LEVEL, то и блокировать пользовательские буферы тоже нет необходимости.

Остается одна проблема - пользовательский поток может передать заведомо неверный адрес буфера, например, попадающий в системное адресное пространство или адрес невыделенной области памяти и т.п. Или пользовательский процесс может быть многопоточным, и один из потоков может освободить память занимаемую буфером во время обработки драйвером запроса ввода-вывода. Такие ситуации надо просто предвидеть и корректно обрабатывать. Использование структурной обработки исключений (Structured Exception Handling, SEH) при этом обязательно (пример см. \src\Article4-5\NtBuild). Учтите только, что хотя структурная обработка исключений в режиме ядра принципиально ничем не отличается от режима пользователя, обрабатывать таким образом все исключения не удастся. Например, попытка деления на ноль приведет к появлению BSOD даже при установленном обработчике SEH.


Процедура обработки IRP типа IRP_MJ_DEVICE_CONTROL

Запрос типа IRP_MJ_DEVICE_CONTROL направляется драйверу, когда код режима пользователя вызывает функцию DeviceIoControl.


     and dwBytesReturned, 0

Если произойдет ошибка, то диспетчер ввода-вывода не должен ничего копировать в пользовательский буфер.


     mov esi, pIrp
     assume esi:ptr _IRP

     IoGetCurrentIrpStackLocation esi
     mov edi, eax
     assume edi:ptr IO_STACK_LOCATION

Макрос IoGetCurrentIrpStackLocation извлекает из структуры _IRP указатель на текущий блок стека ввода-вывода (I/O stack). Это структура IO_STACK_LOCATION. Таких блоков в пакете запроса ввода-вывода может быть несколько, в зависимости от того, сколько драйверов обслуживают запрос. У нас драйвер один и блок стека будет один.


     .if [edi].Parameters.DeviceIoControl.IoControlCode == IOCTL_GET_PHYS_ADDRESS

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

Определение значения управляющего кода ввода-вывода IOCTL_GET_PHYS_ADDRESS и констант NUM_DATA_ENTRY и DATA_SIZE вынесено в отдельный файл common.inc


 NUM_DATA_ENTRY         equ 4
 DATA_SIZE              equ (sizeof DWORD) * NUM_DATA_ENTRY
 IOCTL_GET_PHYS_ADDRESS equ CTL_CODE(FILE_DEVICE_UNKNOWN, 800h, METHOD_BUFFERED, FILE_READ_ACCESS + FILE_WRITE_ACCESS)

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


         .if ( [edi].Parameters.DeviceIoControl.OutputBufferLength >= DATA_SIZE ) && ( [edi].Parameters.DeviceIoControl.InputBufferLength >= DATA_SIZE )

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

Поля OutputBufferLength и InputBufferLength вложенной в IO_STACK_LOCATION структуры DeviceIoControl соответствуют параметрам nOutBufferSize и nInBufferSize функции режима пользователя DeviceIoControl.


             mov edi, [esi].AssociatedIrp.SystemBuffer

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


             assume edi:ptr DWORD

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


             xor ebx, ebx
             .while ebx < NUM_DATA_ENTRY

                 invoke GetPhysicalAddress, [edi][ebx*(sizeof DWORD)]

                 mov [edi][ebx*(sizeof DWORD)], eax
                 inc ebx
             .endw

В цикле, повторяющемся NUM_DATA_ENTRY раз, извлекаем из системного буфера подлежащий трансляции виртуальный адрес, и передаем его в функцию GetPhysicalAddress эту самую трансляцию осуществляющую.

Получив преобразованное значение, помещаем его обратно в системный буфер, на то же самое место.


             mov dwBytesReturned, DATA_SIZE
             mov status, STATUS_SUCCESS

Если мы добрались до этой точки, то обработка запроса закончена. Помещаем в переменные dwBytesReturned и status соответствующие значения.


         .else
             mov status, STATUS_BUFFER_TOO_SMALL
         .endif
     .else
         mov status, STATUS_INVALID_DEVICE_REQUEST
     .endif

Если происходит какая-нибудь ошибка, то переменная status получает соответствующий код ошибки.


     assume edi:nothing

     push status
     pop [esi].IoStatus.Status

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


     push dwBytesReturned
     pop [esi].IoStatus.Information

В поле Information блока статуса ввода-вывода помещаем текущее значение переменной dwBytesReturned. Завершая IRP, диспетчер ввода-вывода извлекает из этого поля значение количества байт, которое он должен скопировать из системного в пользовательский буфер, указатель на который передается в параметре lpOutBuffer функции DeviceIoControl на стороне режима пользователя. Это же значение вернется коду режима пользователя в двойном слове, указатель на которое помещен в параметр lpBytesReturned функции DeviceIoControl.

Если произойдет какая-либо ошибка, то переменная dwBytesReturned у нас инициализирована нулевым значением. Если же все пойдет по плану, то в переменной dwBytesReturned окажется значение DATA_SIZE. Именно это количество байт диспетчер ввода-вывода и скопирует в пользовательский буфер.


     assume esi:nothing

     fastcall IofCompleteRequest, pIrp, IO_NO_INCREMENT

     mov eax, status
     ret

Даем указание диспетчеру ввода-вывода завершить обработку IPR и возвращаем системе текущий код состояния.


Процедура трансляции адресов

Код режима ядра, в отличие от кода режима пользователя, может транслировать виртуальные адреса в физические и наоборот. Для этого необходим доступ к каталогу страниц (page directory) и самим таблицам страниц (page tables). В Windows NT для x86-систем каталог страниц процесса расположен по виртуальному адресу 0C0300000h (режим проецирования памяти Physical Address Extension мы не рассматриваем), а таблицы страниц процесса начинаются с виртуального адреса 0C0000000h.

Я не буду рассматривать теорию механизма трансляции адресов - очень подробно об этом можно почитать в рекомендованной в первой части статьи литературе или найти в сети.

Я предполагал, что данный материал будут читать люди с разной подготовкой. Если вы впервые услышали об этих понятиях, можно пропустить этот раздел. А чтобы вам было не так обидно, удалите код процедуры GetPhysicalAddress, а ее вызов замените на вызов функции ядра MmGetPhysicalAddress. Таким образом MmGetPhysicalAddress превращается в "черный ящик", на вход которого поступает виртуальный адрес, а на выходе вы имеете соответствующий ему физический.

Вышеупомянутые структуры индивидуальны для каждого процесса. Т.к. при обработке запроса типа IRP_MJ_DEVICE_CONTROL мы находимся в контексте процесса инициировавшего запрос, то никаких дополнительных действий по переключению адресного контекста нам делать не нужно.


     mov eax, dwAddress
     mov ecx, eax

Сохраняем виртуальный адрес в регистре ecx для дальнейшего использования.


     shr eax, 22

Выделяем старшие 10 бит, которые являются индексом каталога страниц (page directory index).


     shl eax, 2

Умножаем индекс на размер элемента каталога страниц (page directory entry, PDE), равный 4 байтам. Т.о. в регистре eax получаем смещение нужного PDE от начала каталога.


     mov eax, [0C0300000h][eax]

Извлекаем содержимое PDE.


     .if ( eax & (mask pde4kValid) )

12 младших бит PDE (см. запись HARDWARE_PDE4K_X86 в \include\w2k\w2kundoc.inc) содержат атрибуты PDE. Если флаг Valid (бит 0) установлен, то PDE действителен.


         .if !( eax & (mask pde4kLargePage) )

Флаг Large Page (бит 7) указывает, что PDE относится к 4-мегабайтной странице (на данный момент, такие страницы используются ядром (по крайней мере в Windows 2000 это так) для проецирования ntoskrnl.exe и hal.dll в диапазон виртуальных адресов 80000000h - 9FFFFFFFh). Для PDE соответствующих 4-килобайтным и 4-мегабайтным страницам трансляция адреса отличается.


             mov eax, ecx
             shr eax, 10
             and eax, 1111111111111111111100y

Если PDE соответствует 4-килобайтной странице, выделяем биты 12-21, которые являются индексом таблицы страниц (page table index), одновременно "умножая" индекс на размер элемента таблицы страниц (page table entry, PTE) равный 4 байтам. Т.о. в регистре eax получаем смещение нужного PTE от начала всего массива таблиц страниц.


         add eax, 0C0000000h
         mov eax, [eax]

Прибавив базовый адрес массива таблиц страниц процесса, извлекаем PTE.


         .if eax & (mask pteValid)

12 младших бит PТE (см. запись HARDWARE_PTE_X86 в \include\w2k\w2kundoc.inc) содержат атрибуты PTE. Если флаг Valid (бит 0) установлен, то PTE соответствует странице в физической памяти.


             and eax, mask ptePageFrameNumber

Если PTE действителен, то его старшие 20 бит содержат номер фрейма страницы (page frame number, PFN) являющийся номером страницы в пространстве физических адресов. Этой командой мы одним махом выделяем PFN и "умножаем" его на размер страницы (4кб) и получаем физический адрес страницы.


                 and ecx, 00000000000000000000111111111111y
                 add eax, ecx
             .else
                 xor eax, eax
             .endif

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


         .else
             and eax, mask pde4mPageFrameNumber

Если PDE соответствует 4-мегабайтной странице (см. запись HARDWARE_PDE4M_X86 в \include\w2k\w2kundoc.inc), выделяем биты 22-31, получая PFN, который, в случае больших страниц, и является физическим адресом страницы.


             and ecx, 00000000001111111111111111111111y
             add eax, ecx
         .endif
     .else
         xor eax, eax
     .endif

Выделяем и добавляем адрес байта в пределах страницы. Обработку больших страниц я добавил для полноты. В нашем случае, все четыре адреса соответствуют 4-килобайтным страницам.

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

Работа с записями не часто встречается в практике программирования на ассемблере. Если не знакомы с директивой mask, то вместо


 mask pde4kValid
 mask pde4kLargePage
 mask pteValid
 mask ptePageFrameNumber
 mask pde4mPageFrameNumber

используйте


 01y
 010000000y
 01y
 11111111111111111111000000000000y
 11111111110000000000000000000000y




Процедура выгрузки драйвера

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


     invoke IoDeleteSymbolicLink, addr g_usSymbolicLinkName

     mov eax, pDriverObject
     invoke IoDeleteDevice, (DRIVER_OBJECT PTR [eax]).DeviceObject

Тут код говорит сам за себя. В процедуре выгрузки драйвера мы должны произвести действия прямо противоположные действиям в процедуре инициализации, т.е. удалить все созданные нами объекты. Как я уже говорил выше, в режиме ядра никто за нас подтирать не будет.

Таблица 5-1 подытоживает рассмотреный материал. В ней показано, к вызову каких процедур в драйвере приводит обращение кода режима пользователя к той или иной функции ввода-вывода, с указанием контекста и уровня запроса прерывания.

Таблица 5-1. Соответствие пользовательских функций процедурам драйвера


Режим пользователя

Режим ядра

Контекст

IRQL

StartService

DriverEntry

Процесса System

PASSIVE_LEVEL

CreateFile

IRP_MJ_CREATE

Вызывающего процесса

PASSIVE_LEVEL

DeviceIoControl

IRP_MJ_DEVICE_CONTROL

Вызывающего процесса

PASSIVE_LEVEL

ReadFile

IRP_MJ_READ

Вызывающего процесса

PASSIVE_LEVEL

WriteFile

IRP_MJ_WRITE

Вызывающего процесса

PASSIVE_LEVEL

CloseHandle

IRP_MJ_CLEANUP, IRP_MJ_CLOSE

Вызывающего процесса

PASSIVE_LEVEL

ControlService,,SERVICE_CONTROL_STOP

DriverUnload

Процесса System

PASSIVE_LEVEL




Компиляция


 :make

 set drv=skeleton

 \masm32\bin\ml /nologo /c /coff %drv%.bat
 \masm32\bin\link /nologo /driver /base:0x10000 /align:32 /out:%drv%.sys /subsystem:native /ignore:4078 %drv%.obj rsrc.obj

 del %drv%.obj
 move %drv%.sys ..

 echo.
 pause

Все это мы с вами уже разобрали в части 3. Я добавил ключ /ignore:4078, т.к. из-за того, что у нас появилась вторая секция кода "INIT" с отличающимися атрибутами компоновщик выдает предупреждение:


 LINK : warning LNK4078: multiple "INIT" sections found with different attributes (E2000020)

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


Добавляем ресурсы

Каждый уважающий своего создателя драйвер должен сообщать его имя, а также кое-какие дополнительные сведения о себе. Это можно сделать используя файл ресурсов (см. rsrc.rc).


VS_VERSION_INFO VERSIONINFO
 FILEVERSION 1,0,0,0
 PRODUCTVERSION 1,0,0,0
 FILEFLAGSMASK 0x3fL
 FILEFLAGS 0x0L
 FILEOS 0x40004L
 FILETYPE 0x1L
 FILESUBTYPE 0x0L
BEGIN
    BLOCK "StringFileInfo"
    BEGIN
        BLOCK "040904E4"
        BEGIN
            VALUE "Comments", "Written by Four-F\0"
            VALUE "CompanyName", "Four-F Software\0"
            VALUE "FileDescription", "Kernel-Mode Driver VirtToPhys v1.00\0"
            VALUE "FileVersion", "1, 0, 0, 0\0"
            VALUE "InternalName", "VirtualToPhysical\0"
            VALUE "LegalCopyright", "Copyright © 2003, Four-F\0"
            VALUE "OriginalFilename", "VirtToPhys.sys\0"
            VALUE "ProductName", "Kernel-Mode Driver Virtual To Physical Address Converter\0"
            VALUE "ProductVersion", "1, 0, 0, 0\0"
        END
    END
    BLOCK "VarFileInfo"
    BEGIN
        VALUE "Translation", 0x409, 1200
    END
END

Тут ничего принципиально нового. Стандартный ресурсный скрипт. Компилируется и линкуется как обычно. В свойствах файла драйвера можно посмотреть что получилось.


Еще немного об отладке

Вытащить всю (или почти всю) "подноготную" объектов "драйвер" и "устройство" можно с помощью команд driver <имя драйвера> и device <имя устройства> отладчика SoftICE. Вот как это выглядит на моей машине:

Рис. 5-2. Результат выполнения команды driver VirtToPhys

Рис. 5-3. Результат выполнения команды device devVirtToPhys

Как вы понимаете, информация отображаемая SoftICE, в основном, извлекается из структур DRIVER_OBJECT и DEVICE_OBJECT соответственно. Используя эту информацию можно легко найти эти объекты в памяти, поставить точки прерывания на процедуры диспетчеризации и выгрузки драйвера и т.п.


Заключение

Вот мы, наконец, и разобрали основы программирования драйверов режима ядра на языке ассемблера. Надеюсь, эти статьи помогли вам легко "въехать в тему". За дополнительной информацией обращайтесь, прежде всего, к DDK, книге Walter Oney " Programming the Microsoft Windows Driver Model" и журналу "The NT Insider" http://www.osr.com/.

В архиве к этой статье вы обнаружите:

\include\

- некоторые обновленные включаемые файлы;

\src\Article4-5\NtBuild

- код драйвера возвращающего номер сборки (build number) и выпуск системы. Демонстрирует использование функции ReadFile, вида управления буферами neither и использование SEH;

\src\Article4-5\Skeleton

- каркас драйвера режима ядра;

\src\Article4-5\VirtToPhys

- код описанного в данной статье драйвера.

2002-2013 (c) wasm.ru