39775

Виртуальные драйверы и виртуальные машины Windows

Реферат

Информатика, кибернетика и программирование

Основное назначение виртуального драйвера виртуализация устройства т. Разработка нового виртуального драйвера может понадобиться при установке на компьютер новой аппаратуры или нового программного обеспечения предназначенного для обслуживания других приложений которая будет использоваться в многозадачном режиме и для которой в системе Windows не предусмотрено средств виртуализации. В первом случае речь идет о приложениях работающих в плоской модели памяти на уровне привилегий 3 это характерно для 32разрядных приложений Windows;...

Русский

2013-10-08

119 KB

14 чел.

Виртуальные драйверы и виртуальные машины Windows

Работа операционных систем Windows 95/98 (как и Windows 3.1) в значительной степени основана на использовании специального рода программ - так называемых виртуальных драйверов устройств (или просто виртуальных драйверов, virtual device). Основное назначение виртуального драйвера - виртуализация устройства, т. е. возможность нескольким приложениям одновременно использовать одно и то же физическое устройство. Например, виртуальный драйвер дисплея (VDD) обеспечивает многооконный режим, в котором каждое приложение, выводя информацию на экран, считает, что весь физический экран находится в его распоряжении, в то время как в действительности вывод приложения поступает в выделенное для него окно. Виртуальный контроллер прерываний (VPICD) дает возможность нескольким приложениям совместно использовать единую систему прерываний компьютера. Виртуальный драйвер клавиатуры (VKD) позволяет вводить с клавиатуры символьные строки в любую из выполняемых программ. Разработка нового виртуального драйвера может понадобиться при установке на компьютер новой аппаратуры (или нового программного обеспечения, предназначенного для обслуживания других приложений), которая будет использоваться в многозадачном режиме и для которой в системе Windows не предусмотрено средств виртуализации.

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

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

Одним из базовых понятий системы Windows является понятие виртуальной машины. Согласно документации Microsoft, виртуальной машиной (VM) называется выполняемая задача, состоящая из приложения, поддерживающего программного обеспечения (например, программ DOS и BIOS), памяти и регистров процессора. Каждая виртуальная машина обладает собственным адресным пространством, пространством ввода-вывода и таблицей векторов прерываний. В адресное пространство VM отображаются ПЗУ BIOS, драйверы и другие программы DOS, а также загруженные до запуска Windows резидентные программы, что обеспечивает доступ к ним прикладных программ, выполняемых под управлением системы Windows. В состав виртуальной машины входят виртуальные аппаратные регистры, в частности виртуальные маски прерываний, виртуальные флаги процессора и др.

Первая виртуальная машина, создаваемая после загрузки Windows и называемая системной виртуальной машиной, в системах Windows 95/98 предназначена для выполнения 16- и 32-разрядных приложений Windows. Для каждого сеанса DOS создается своя виртуальная машина, и таким образом одновременно в системе может существовать несколько виртуальных машин,

Управление виртуальными машинами возлагается на менеджер виртуальных машин (Virtual machine manager, VMM), являющийся ядром операционных систем Windows 95/98. VMM представляет собой 32-разрядную систему защищенного режима, работающую на нулевом уровне привилегий в плоской модели памяти. В функции VMM входит создание, управление и завершение виртуальных машин, а также управление памятью, процессами, прерываниями и нарушениями защиты. Так, если приложение делает попытку записи или чтения по адресам памяти, не принадлежащим данной виртуальной машине, или выполняет команды ввода-вывода в запрещенные порты, процессор возбуждает исключение и управление передается VMM, который анализирует причину исключения и либо с помощью виртуальных драйверов обеспечивает выполнение затребованной операции, либо аварийно завершает приложение.

Для обеспечения функционирования VMM и виртуальных драйверов система создает два глобальных селектора: 28h для программных кодов и 30h для системных полей данных. Дескрипторы обоих селекторов почти одинаковы: в них указано нулевое значение DPL, нулевой базовый линейный адрес и граница 4 Гбайт (рис. 1). В регистр CS загружается селектор 28h, во все остальные сегментные регистры (DS, SS, ES, FS и GS) - селектор 30h. Ни VMM, ни виртуальные драйверы никогдачне изменяют' содержимое сегментных регистров.

:GDT  30

Sel Type Base             Limit               DPL         Attributes

0030    Data32 00000000       FFFFFFFF     0               P         RW

Puc. 1. Дескриптор З0h

VMM вместе с системными виртуальными драйверами предоставляет большое количество служебных функций, позволяющих виртуальным драйверам активизировать по ходу своего выполнения те или иные системные процедуры и алгоритмы. Например, функция VMM _MapPhysToLinear отображает заданный участок физических адресов на линейное адресное пространство, что дает возможность виртуальному драйверу выполнять чтение или запись в физической памяти; функции Install_Handler и Install_Mult_IO_Handlers устанавливают в системе прикладные процедуры обслуживания заданных портов; функция Simulate_Push помещает указанный параметр в стек приложения. Служебные функции имеются и у системных виртуальных драйверов. Так, виртуальный контроллер прерываний VPICD позволяет с помощью функции VPICD_Virtualize_IRQ организовать прикладную обработку аппаратных прерываний, а виртуальный таймер VTD предоставляет функции VTD_Begin_Min_Period и VTDJEnd_Min_Period для управления частотой системного таймера. Служебные функции VMM и системных виртуальных драйверов, в отличие от функций DOS или Windows, не могут вызываться непосредственно из приложения; обращение к ним возможно только из виртуальных драйверов.

Взаимодействуя с VMM и виртуальными машинами, виртуальные драйверы используют целый ряд системных полей и структур данных. Одним из важнейших системных идентификаторов, создаваемых VMM для каждой виртуальной машины, является ее дескриптор. Дескриптор однозначно идентифицирует виртуальную машину и используется при вызовах функций VMM для задания VM, к которой обращено требуемое действие. Заметим, что дескриптор виртуальной машины является базовым адресом, от которого ведется отсчет адресов ряда важных полей VMM. Так, в двойном слове по адресу [дескриптор VM - 8J располагается адрес таблицы векторов прерываний защищенного режима.

Дескриптор VM фактически является линейным 32-разрядным адресом управляющего блока данной VM. Управляющий блок представляет собой структуру из пяти двойных слов, содержащую информацию о виртуальной машине. Эта структура определена в файле VMM.INC и имеет следующий вид:

cb_s    struc

CB_VM__Status  dd   ?  ; Слово состояния VM

CB_High_Linear  dd   ?  ; Старший линейный адрес

CB_Client_Pointer dd   ?  ; Адрес структуры клиента

CB_VMID  dd   ?  ; Идентификатор VM

CB_Signature        dd    ?    ; Сигнатура 

cb_s    ends

В слове состояния VM каждый бит закреплен за определенной характеристикой текущего состояния VM. Так, установленный бит 1 (символическое обозначение VMStat_Background) говорит о том, что VM выполняется в фоновом режиме; бит 6 (VMStat_PM_App) свидетельствует о наличии в VM приложения защищенного режима, бит 7 (VMStat_PM_Use32) характеризует 32-разрядное приложение защищенного режима и т. д. Иногда в процессе отладки виртуального драйвера приходится обращаться к этому слову для определения состояния виртуальной машины.

Старший линейный адрес. При запуске в рамках Windows одного или нескольких сеансов DOS (и создания соответствующих виртуальных машин) происходит копирование 1-го мегабайта физического адресного пространства в различные участки расширенной памяти. В каждой копии DOS имеется своя таблица векторов прерываний, своя видеопамять и даже своя копия ПЗУ BIOS, что дает возможность приложениям DOS различных сеансов параллельно и независимо работать каждому со своей памятью, не разрушая память других сеансов. Для того чтобы с сеансами DOS могли взаимодействовать VMM или виртуальные драйверы, физическая память сеансов DOS отображается на некоторые линейные адреса (4-го гигабайта линейного адресного пространства), которые и называются старшими линейными адресами. Для каждой VM существует собственный старший адрес (рис. 2).

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

Структура клиента, адрес которой СВ_Client_Pointer входит в управляющий блок, является важнейшим набором данных, обеспечивающим обмен информацией между приложением и виртуальным драйвером. Когда при вызове виртуального драйвера процессор переходит на нулевой уровень привилегий, в стеке уровня 0 (не в стеке приложения!) сохраняются значения всех регистров вызывающего приложения, соответствующие точке вызова драйвера. Совокупность этих значений и называется структурой клиента. При входе в драйвер адрес структуры клиента находится в регистре ЕВР, а обращение к отдельным элементам этой структуры осуществляется с помощью наглядных символических обозначений вида Client_AX, Client_FLAGS, Client_CS и т. д.:

movzx EAX,[EBP.Client_AX]  ;Передача АХ приложения в ЕАХ драйвера

mov   [EBP.Client_DX],data   ;Передача данного из драйвера

DX приложения

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

Структура виртуального драйвера

Виртуальные драйверы обычно пишутся на языке ассемблера, хотя внутренние процедуры драйвера вполне могут составляться на языке Си (Си++). Использование языка высокого уровня упрощает реализацию вычислительных и логических алгоритмов в процедурах драйвера, но, с другой стороны, делает текст драйвера менее наглядным. Для создания выполнимого модуля надо использовать 32-разрядные ассемблер и компоновщик, в частности входящие в пакет DDK.

Рассмотрим прежде всего общую структуру виртуального драйвера, а также правила его подготовки и загрузки. В примере 1 приведен текст простейшего виртуального драйвера для систем Windows 95/98, который не выполняет никакой работы, хотя и может быть установлен в системе.

Пример 1. Структура виртуального драйвера

.386р ;Будут использоваться  32-разрядные регистры

.XLIST ;Подавление  включения  в  листинг  текста  vmm.inc

include vmm.inc ;Подключение файла vmm.inc

.LIST ;Разрешение  дальнейшего  вывода   в  листинг

;Блок  описания  драйвера

Declare_Virtual_Device VMyD, 1, 0, VMyD_Control, 8000h, \ Undefined_Init_Order, V86_API_Handler, PM_API_Handler

; Сегмент инициализации реального режима

VxD_REAL_INIT_SEG

;Процедура инициализации реального режима

BeginProc VMyD_Real_Init    ;Точка входа при инициализации

mov   AH,09h        ;Функция DOS вывода на экран

mov   DX,offset msg  ;Адрес выводимого сообщения

int   21h           ;Вызов DOS

mov   AX, Device_Load_Ok  ;Код успешного завершения

xor   BX,BX         ;Дополнительные

xor   SI,SI         ;данные

xor   EDX,EDX       ;отсутствуют

ret

msg db 'Виртуальный драйвер VMyD загружен',13,10,'$'

EndProc   VMyD_Real_Init

VxD_REAL_INIT_ENDS

VxD_DATA_SEG

;Здесь размещаются данные, используемые драйвером

VxD_DATA_ENDS

;сегмент защищенного режима

VxD_CODE_SEG

;Управляющая процедура для обработки системных сообщений Windows

BeginProc VMyD_Control

;Сюда могут быть включены процедуры обработки различных

;системных сообщений Windows: Device_Init инициализации драйвера,

;Create_VM создания новой виртуальной машины, Begin_PM_App запуска

;приложения защищенного режима и End_PM_App его завершения и др.

clc

ret

EndProc VMyD_Control

;Процедура, вызываемая из приложения реального режима (приложения DOS) BeginProc V86_API_Handler

;Сюда включаются содержательные процедуры драйвера, которые

;должны выполняться при вызове драйвера из приложений реального режима

ret. ;Возврат из драйвера в вызывающее приложение

EndProc V86_API_Handler

;Процедура,"вызываемая из приложения защищенного режима (приложения ;Windows)

BeginProc PM_API_Handler

;Сюда включаются содержательные процедуры драйвера, которые

;должны выполняться при вызове драйвера из приложений защищенного режима

ret ;Возврат из драйвера в вызывающее приложение

EndProc PM_API_Handler 

VxD_CODE_ENDS 

end VMyD_Real_Init        ;Конец текста драйвера с указанием точки входа

Исходный текст драйвера начинается с директивы ассемблера .386р, позволяющей использовать расширенный набор команд современных процессоров и, в частности, привилегированных команд защищенного режима. Следующая далее директива .XLIST подавляет вывод в листинг трансляции всех последующих предложений программы вплоть до отмены ее действия директивой .LIST. В нашем случае подавляется вывод в листинг весьма обширного файла VMM.INC с определениями макросов и констант, фактически обеспечивающего использование в драйвере средств VMM.

Как видно из приведенного листинга, драйвер в простейшем случае состоит из блока описания драйвера и_трех сегментов: сегмента инициализации реального режима VxD_REAL_INIT, в котором размещается процедура инициализации реального режима (вместе с относящимися к ней данными); сегмента данных VxD_DATA_SEG со всеми данными, которые могут потребоваться драйверу в процессе его работы; сегмента команд защищенного режима VxD_CODE, содержащего в нашем случае процедуры VMyD_Control, V86_API_Handler и PM_API_Handler (имена процедур произвольны).

В тексте драйвера широко используются макросы, определенные в файле VMM.INC. Так, макросы VxD_REAL_INIT_SEG и VxD_REAL_INIT_ENDS задают начало и конец сегмента инициализации реального режима, макросы VxD_ CODE_SEG и VxD_CODE_ENDS - начало и конец сегмента защищенного режима, а макросы BeginProc и EndProc - границы процедур, входящих в состав драйвера. Имена макросов можно набирать как строчными, так и прописными буквами.

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

имя драйвера;

номер версии и подверсии;

имя управляющей процедуры;

идентификационный номер драйвера;

порядок инициализации;

имя процедуры обслуживания реального режима;

имя процедуры обслуживания защищенного режима.

В нашем случае драйверу дано произвольное имя VMyD, управляющей процедуре (которая обязательно должна присутствовать, хотя у нас она фактически пуста) -VMyD_Control, процедурам обслуживания реального и защищенного режимов, которые в дальнейшем мы будем называть API-процедурами (Application Program Interface, интерфейс прикладных программ) - V86_API_Handler и PM_API_Handler соответственно. Для версии выбран номер 1.0, а для идентификационного кода - 8000h. При разработке коммерческого виртуального драйвера его следует зарегистрировать в корпорации Microsoft и получить для него идентификационный код. Порядок инициализации важен для драйверов, обращающихся друг к другу; для наших драйверов порядок инициализации не имеет значения, что указано с помощью константы Undefmed_Init_Order.

Процедура инициализации реального режима VMyD_Real_Init вызывается автоматически в процессе загрузки драйвера, когда процессор еще не перешел в защищенный режим. Поскольку процедура выполняется в реальном режиме, в ней возможен вызов функций DOS. У нас она используется для вывода на экран (в процессе загрузки Windows) сообщения о загрузке нашего драйвера. При входе в процедуру инициализации реального режима регистры CS, DS и ES имеют одно и то же значение, равное сегментному адресу сегмента реального режима, а регистр IP содержит 0. Таким образом, процедура инициализации должна начинаться с программных строк, вслед за которыми могут располагаться любые поля данных, используемые на этом этапе инициализации драйвера.

API-процедуры являются, можно сказать, содержательной частью драйвера. Эти процедуры, выполняемые на нулевом уровне привилегий в плоской модели памяти, могут быть вызваны из любой прикладной программы (выполняемой, естественно, на третьем уровне защиты). Для обращения к драйверу из приложений DOS (реальный режим) и Windows (защищенный режим) предусматриваются две различные API-процедуры; если действия драйвера в ответ на обращение программ в обоих случаях одинаковы, в соответствующих полях блока описания драйвера можно указать имя единственной процедуры. В некоторых случаях драйвер работает сам по себе, без обращения к нему из программы пользователя, тогда как сами процедуры, так и их имена в блоке описания драйвера отсутствуют. В дальнейшем мы будем рассматривать только драйверы, предназначенные для работы с приложениями Windows и в блоке описания драйвера имя API-процедуры реального режима будет отсутствовать:

Declare_Virtual_Device VMyD, 1, 0, VMyD_Control, 8000h, \ Undefined_Init_Order,,API_Handler

Для ускорения процесса подготовки выполнимого модуля виртуального драйвера удобно создать пакет из трех файлов. Приводимый ниже пример их содержимого предполагает, что пакет DDK установлен на диске G: в каталоге DDK95, исходный файл с текстом драйвера имеет имя VMYD.ASM, а выполнимый модуль драйвера -VMYD.VXD.

Файл WIN95.BAT

g:\ddk95\masm611 c\ml /coff /DBLD_COFF /Zi /Fl /Sn /DMASM6 /с /Сх vmyd.asm

g:\ddk95\msvc20\link vmyd.obj @vmyd.lnk

del vmyd.obj

Файл  VMYD.DEF

LIBRARY VMYD

DESCRIPTION 'Virtual VMyD driver'

EXETYPE DEV386

SEGMENTS

_LTEXT CLASS 'LCODE1 PRELOAD NONDISCARDABLE

_LDATA CLASS 'LCODE1 PRELOAD NONDISCARDABLE

_RCODE CLASS 'RCODE'

EXPORTS

VMyD_DDB @1

Файл  VMYD.LNK

DEBUG

DEBUGTYPE:BOTH

MACHINE:I386

PDB:NONE

DEF:VMYD.DEF

OUT:VMYD.VXD

VXD

Для того чтобы в операторе include в исходном тексте драйвера не описывать путь к файлу VMM.INC, можно в файл AUTOEXEC.BAT включить команду SET INCLUDE=g:\ddk95\inc32

Загружаемый модуль драйвера подготавливается запуском в сеансе DOS описанного выше командного файла W95.BAT.

Установка созданного драйвера в системе осуществляется путем включения в раздел [386Enh] файла SYSTEM.INI следующей строки (в предположении, что программа драйвера находится в каталоге DRIVERS диска F:): DEVICE=f:\drivers\vmyd.vxd

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

PAGE   \* MERGEFORMAT 1


 

А также другие работы, которые могут Вас заинтересовать

71702. Модуляция гармонических колебаний 540.84 KB
  Под модуляцией понимают процесс изменения одного или нескольких параметров физического процесса по закону передаваемого сообщения. Так, например, если моделью физического процесса является функция f(a, b, c, d, t), то параметры a, b, c, d можно использовать для осуществления модуляции.
71703. ПРОЦЕССЫ 503.52 KB
  В головном процессе создаются/открываются два файла: текстовый (несколько строк) и двоичный (ряд арифметических данных). Информация об открытых файлах (дескрипторы) передается в дочерние процессы на этапе их создания через командную строку.
71704. Решение задачи классификация и регрессии с помощью деревьев решений 136.54 KB
  Цель работы: изучение алгоритмов построения деревьев решений; создание и исследование классификационных и регрессионных моделей с помощью деревьев решений Индивидуальное задание: seeds Data Set Attribute Information: To construct the data, seven geometric parameters of wheat...
71706. Модуляция 602 KB
  Определить зависимость качества модуляции сигнала от уровня шума. Исходные данные На рисунке 1 представлена Sмодель: Модуляция гармонических колебаний которая позволяет изменять тип модуляции ее параметры например частоту а также параметры канала связи...
71707. Доступ к базам данных из программ на языке Java 378 KB
  Операции с данными в SQL Операции с данными позволяют получить значения одно нескольких или всех полей базы данных а также добавлять или удалять записи строки из таблицы либо изменять значения полей таблицы.
71708. Редактирование новости 50.5 KB
  Состоялся благотворительный аукцион в пользу Анисимовского детского дома Около 150 тысяч рублей которые удалось выручить организаторам аукциона администрация Анисимовского детского дома Детский дом Анисимовский МОУ Детский дом для детей оставшихся без попечения родителей...
71709. Команды изменения данных 60.5 KB
  При создании и дальнейшем сопровождении базы данных обычно возникает задача добавления новых и удаления ненужных записей а также изменения содержимого ячеек таблицы. Запросы начинающиеся с этих ключевых слов не возвращают данные в виде виртуальной таблицы...
71710. Определение данных 85 KB
  Для создания таблицы необходимо указать ее имя и определить столбцы. Определение столбца включает его имя и тип. Если указывается длина столбца, то она заключается в круглые скобки после типа. Кроме того, можно указать ограничения для столбца.