НАУКА и ОБРАЗОВАНИЕ

УДК 004. 451

МГТУ им. Н.Э. Баумана

chernen@bmstu.ru

Цель статьи - построение формализованной структурной модели операционной системы Windows2000 - актуальной операционной системы, предназначенной для работы на современной аппаратной базе, поддерживающей новые процессорные архитектуры. Windows 2000 – серверная операционная система, следовательно, особое внимание ее разработчики уделяли обеспечению надежности и безопасности ОС. Однако эта ОС построена таким образом, что расширения ее ядра не изолированы и выполняются как отдельные процессы в режиме ядра, что потенциально создает многие проблемы в области безопасности [3]. Кроме того, Windows 2000, в отличие от более поздних систем от Microsoft, не обладает дополнительными структурными элементами, усложняющими процесс формализации.

Вся информация, изложенная в статье, получена из открытых источников (MicrosoftPress [1]), или же добыта самостоятельно в результате реверс-исследования компонентов системы.

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

Как было отмечено ранее, при описании модели ОС возьмем за основу ее структурный состав, отложив построение функциональной модели на будущее.

 Итак, определим структуру Windows 2000 в целом следующим образом:

где SBS – блок подсистемы окружения, NTD– библиотека системной поддержки ntdll.dll, EXC– исполнительная система, KRN– ядро, HAL– уровень абстракций от оборудования, DRV– драйверы устройств, SPR– системные процессы.

Структурная модель блока подсистем окружения

Прежде чем переходить к непосредственному построению модели блока подсистем окружения отметим, что в современных ОС Windows, сделанных на базе технологий NT, реализована только одна подсистема окружения – Windows [1], однако для точности модели мы рассмотрим все возможные подсистемы. Формализованная модель блока подсистем окружения представляет собой следующее:

где SS – множество подсистем окружения, RQ– подсистемы, загружаемые при старте системы (список), OP– подсистемы, запускаемые по требованию (список).

где subs_i– подсистема окружения. Подсистема окружения по сути – совокупность некоторых программных компонентов. Опишем их.

где subs_NM– наименование подсистемы окружения;

subs_PC– процесс подсистемы окружения (исполняемый образ);

subs_DLL– динамически подключаемые библиотеки конкретной подсистемы окружения;

subs_DRV – драйвер подсистемы окружения;

subs_T– тип подсистемы окружения;

subs_{DRV_G}– драйверы графических устройств.

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

где subs_dll_i– DLLподсистемы окружения.

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

где SUBT– множество типов подсистем окружения;

subt_m – основная подсистема (Windows);

subt_a – дополнительная подсистема (OS/2, POSIX).

Основная подсистема окружения может содержать в своем составе драйверы графических устройств, а именно: драйверы графического дисплея, драйверы принтеров и минипорт-драйверы видеокарт.

где subs_{GD_DRV} – драйвер графического устройства;

subs_T– тип графического устройства;

SUBGDT– множество типов графических устройств;

subgd_d– драйвер графического дисплея;

subgd_p– драйвер принтера;

subgd_v– минипорт-драйвер видеоадаптера.

Структурная модель библиотеки системной поддержки

Ntdll.dll – специальная библиотека системной поддержки Windows. Она содержит в себе следующие компоненты: интерфейсы диспетчера системных сервисов к сервисам исполнительной системы, внутренние функции поддержки, диспетчер куч, функции для взаимодействия с процессом подсистемы Windows, универсальные функции библиотеки времени выполнения, диспетчер исключений и диспетчер асинхронных вызовов процедур [1]. Определим библиотеку системной поддержки следующим образом:

где DSS– функции интерфейса диспетчера системных сервисов;

ISF – внутренние функции поддержки;

HDF– функции диспетчера куч;

CRS– функции для взаимодействия с процессом основной подсистемы;

RTL – универсальные функции библиотеки времени выполнения;

DEX – функции диспетчера исключений;

APC – функции диспетчера прерываний APC (Asynchronousprocedurecall).

Структурная модель исполнительной системы

Исполнительная система находится на верхнем уровне ntoskrnl.exeи обеспечивает выполнение основных функций ОС.

Мы считаем целесообразным построить две модели исполнительной системы (ИС). В первой модели отразим функциональный состав ИС, во второй – структурную организацию ИС.

Итак, с позиций функционального набора, исполнительная система может быть описана следующим образом:

где SSF– экспортируемые исполнительной системой функции, доступные для вызова из пользовательского режима;

DDF – функции драйверов устройств, вызываемые через DeviceIOControl;

KSF – экспортируемые функции, доступные для вызова только из режима ядра;

GNE – функции, определенные как глобальные, но не являющиеся экспортируемыми;

ING – внутренние функции в каком-либо модуле, не определенные как глобальные.

Для описания структуры исполнительной системы будем использовать следующую модель:

где DCONF– диспетчер конфигурации, отвечающий за реализацию и управление системным реестром;

DPT– диспетчер процессов и потоков (управление потоками и процессами реализовано в ядре, в исполнительной системе — только некоторые дополнительные функции);

MNP– монитор состояния защиты, реализующий политики безопасности на локальном компьютере;

DIO– диспетчер ввода-вывода, реализующий аппаратный ввод-вывод и отвечающий за перенаправление ввода-вывода нужным драйверам устройств;

DPP– диспетчер PlugandPlay, определяющий, какие драйверы нужны для конкретного устройства, и загружающий их. Также распределяет ресурсы для каждого устройства и оповещает систему об изменениях в аппаратном обеспечении системы.

DEP– диспетчер электропитания. Контролирует изменение энергопотребления отдельных устройств и посылает соответствующие уведомления драйверам устройств.

PWMI– подпрограммы WDMWindowsManagementInstrumentation, позволяющие драйверам публиковать информацию о своих характеристиках и о своей конфигурации, а также получать команды от службы WMIпользовательского режима;

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

DMEM– диспетчер памяти, реализующий виртуальную память, обрабатывающий исключения PageFault и обеспечивающий низкоуровневую поддержку диспетчера кэша;

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

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

DOBJ– диспетчер объектов. Создает, управляет и удаляет объекты  и абстрактные типы данных исполнительной системы, используемые для представления процессов, потоков и синхронизирующих объектов.

TLPC– механизм LPC (LocalProcedureCall), передающий сообщения между клиентскими и серверными процессами на одном компьютере; оптимизированный аналог RPC;

SF– блок стандартных библиотечных функций (обработка строк, арифметические операции, преобразование типов данных, обработка структур безопасности);

SEXC– подпрограммы поддержки исполнительной системы. Предназначены для выделения памяти, доступа к памяти со взаимоблокировкой; также эти подпрограммы содержат два специальных типа синхронизирующих объектов: ресурс и быстрый мьютекс.

Структурная модель ядра операционной системы

Ядро ОС Windows 2000 состоит из набора функций в ntoskrnl.exe, представляющих фундаментальные механизмы (в т.ч. планирования потоков и синхронизация), которые используются исполнительной системой и низкоуровневыми средствами абстрагирования от оборудования. Ядро не участвует в принятии решений, связанных с системной политикой, оно лишь реализует системные механизмы для других компонентов системы.

Ядро ОС состоит из т.н. «объектов ядра», которые представляют собой набор простых объектов для контроля обработки данных процессором. По сути, объекты исполнительной системы, как правило, инкапсулируют в себе один или несколько объектов ядра.

Формально определим ядро операционной системы следующим образом:

где OBJS– объекты ядра (см. выше);

INTR – семантически идентичные и переносимые между архитектурами интерфейсы (для обеспечения абстрагирования от оборудования);

SINT –  x86-специфичные интерфейсы для поддержки старых программ MS-DOS.

где objs–  собственно объекты ядра (данные и код);

objs_T– класс объекта ядра;

OBJ_T– множество классов объектов ядра.

где

c_obj– управляющий объект (controlobject);

d_obj – объектдиспетчера (dispatcher object).

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

Опишем каждый класс.

где

apco– APC-объекты;

dpco –DPC-объекты (DPC – Deferred Procedure Call);

dioo– объекты, используемые диспетчером ввода-вывода.

где

m_o–мьютекс;

e_o– событие;

s_o– семафор;

t_o– таймер;

wt_o– ожидаемый таймер.

Структурная модель уровня абстрагирования от оборудования

Одна из важнейших особенностей ОС Windows2000 – переносимость между платформами. Ключевой компонент, обеспечивающий такую переносимость, – уровень абстрагирования от оборудования – HAL [1, 2, 4]. HAL – загружаемый модуль режима ядра (hal.dll), предоставляющий низкоуровневый интерфейс с аппаратной платформой. Все остальные компоненты системы обращаются к оборудованию только через HAL. Переносимость достигается путем использования различных слоев абстрагирования от оборудования. В HALсодержатся системные функции и экспортируемые символы, используемые драйверами. Построим модель HAL следующим образом:

где

HF–набор функций HAL;

HS–экспортируемые символы HAL;

hf_i – функции HAL.

где

hf–собственно функция HAL;

hf_T– тип функции.

где

HFT– множество типов функций HAL;

fx –функция исполнительной системы, реализованная в HAL;

fh – функция HAL, предназначенная для сокрытия аппаратных различий;

fk – функция ядра ОС, перенесенная в HAL;

fio – функция диспетчера ввода-вывода, перенесенная в HAL;

fs – специальная функция HAL (например, макрокоманды для записи/чтения в/из портов).

Структурная модель драйверов устройств

Драйверы устройств в Windows – это бинарные программы, выполняющиеся в нулевом кольце привилегий. Работой драйвера управляет подсистема ввода-вывода ОС. Модель драйвера устройства представим следующим образом:

где

drv_i – драйвер;

drv – файл драйвера (бинарный код);

drv_T – тип драйвера;

drv_TR – режим работы драйвера (рассмотрено далее);

drv_WDM – соответствие драйвера модели WDM(да или нет);

drv_ML– признак того, что драйвер является многоуровневым (аналогично);

DRV_T – множество типов драйверов.

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

где

DRV_TR – множество режимов работы драйвера;

ring0 – драйвер предназначен для работы в контексте системного процесса;

ring3 – драйвер предназначен для работы в контексте пользовательского процесса;

int – драйвер предназначен для работы в качестве обработчика прерывания.

ОС Windowsработает с драйверами следующих типов [1]:

где

vd_d – драйверы виртуального устройства (virtualdevicedriver, VDD), используются для эмуляции 16-разрядных программ MS-DOS. Эти драйверы позволяют программам MS-DOSобращаться к системным структурам и портам ввода-вывода. Драйверы этого типа выполняются в пользовательском режиме.

p_d – драйверы принтера. Транслируют аппаратно-независимые запросы к графическому устройству в команды для конкретного принтера. Затем эти команды направляются непосредственно драйверу принтера, работающему в режиме ядра, или USB-шине. Драйверы этого типа выполняются в пользовательском режиме.

fs_d – драйверы файловой системы. Принимают запросы на ввод-вывод и формируют более специфические запросы драйверам устройств.

pp_d – Plug and Play драйверы. В их число входят драйверы для устройств массовой памяти, видеоадаптеров, устройств ввода и сетевых адаптеров.

up_d – драйверы, не отвечающие спецификации PlugandPlay – расширения ядра. Расширяют функциональность системы, предоставляя доступ из пользовательского режима к сервисам и драйверам режима ядра.

b_d – Драйверы шин. Управляют логическими или физическими шинами. Отвечают за распознавание новых устройств и за управление электропитанием шины.

fn_d – Функциональные драйверы. Управляют конкретным типом устройств. Экспортируют рабочий интерфейс операционной системе.

fl_d – Драйверы-фильтры. Дополняют или изменяют функциональность устройства или другого драйвера.

dc_d – Драйверы класса устройств. Реализуют обработку ввода-вывода для целого класса устройств. Используются для классов устройств со стандартизированными аппаратными интерфейсами.

p_d – порт-драйверы. Обрабатывают запросы на ввод-вывод для определенного типа порта ввода-вывода.

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

Процедурный состав программного модуля драйвера следующий:

где

ad_p – процедура добавления устройства (реализуются только в PnP-драйверах; через эту процедуру диспетчер PnPпосылает уведомление драйверу при обнаружении в системе устройства соответствующего типа);

{d_p_i} – процедуры диспетчеризации (основные функции, предоставляемые драйвером устройства);

io_p – процедура инициации ввода-вывода (с помощью этой процедуры драйвер может инициировать передачу данных как на устройство, так и считывание данных с него);

hi_p – процедура обслуживания прерываний (когда устройство генерирует прерывание, диспетчер ввода-вывода передает управление этой процедуре);

dpc_p – DPC-процедура (выполняется при обработке прерываний; инициирует завершение текущей операции ввода-вывода и запускает новую из очереди этого устройства);

i_p – инициализирующая процедура (диспетчер ввода-вывода выполняет ее при загрузке драйвера, регистрируя в себе остальные процедуры драйвера и выполняя базовую инициализацию структур драйвера).

Структурная модель системных процессов

В каждой системе Windows 2000 выполняются некоторые служебные процессы. Представим структуру блока системных процессов:

где

Idle –процесс простоя системы, ОС создает по одному такому процессу для каждого процессора;

Sysm – процесс-носитель системных потоков, выполняющихся в режиме ядра.

Smss – процесс «диспетчер сеансов». Участвует в процессе загрузки системы и запускает процессы подсистем (Csrss.exeи Winlogon.exe).

Csrs –процесс основной подсистемы. Назначение описано выше.

Winl – процесс входа в систему. С помощью библиотеки GINAпроводит аутентификацию пользователя, полученные данные отправляет процессу Lsass.exe.

Serv – диспетчер управления сервисами (Services.exe) и создаваемые им дочерние процессы сервисов (например, Svchost.exe).

Lsas – процесс локальной аутентификации. Получает от Winlogon.exeаутентификационные данные пользователя, проводит их проверку. В случае успеха генерирует объект «маркер доступа», который содержит профиль безопасности пользователя.

В данной статье предпринята попытка построения формализованной  структурной модели операционной системы Windows 2000. Здесь описаны основные структурные компоненты системы с указанием их взаимосвязи.

Литература

1.    Руссинович, М., Соломон, Д. Внутреннее устройство MicrosoftWindows: WindowsServer 2003; WindowsXPи Windows 2000. Мастер-класс. / Пер. с англ. – 4-е изд. – М.: Издательстко-торговый дом «Русская Редакция»; СПб.: Питер, 2005. – 992 с.: ил. ISBN 5-469-01174-7.

2.    Таненбаум, Э., Вудхалл, А. Операционные системы: разработка и реализация. Классика CS. – СПб.: Питер, 2006. – 576 с.: ил. ISBN5-469-00148-2.

3.    Bacon J., Harris T. Operating Systems: Concurrent and Distributed Software Design - Addison Wesley, 2003. – 720 p. ISBN 0-321-11789-1

4.    Silberschatz, A., Galvin, P., Gagne G. Operating System Concepts, 6^th Edition. – John Wiley & Sons Inc., 2002. – 842 p. ISBN 0-471-41743-2.