Олицетворение (impersonation) — мощное средство, часто используемое в модели защиты Windows. Олицетворение также применяется в модели программирования «клиент-сервер». Например, серверное приложение может экспортировать ресурсы (файлы, принтеры или базы данных). Клиенты, которые хотят обратиться к этим ресурсам, посылают серверу запрос. Получив запрос, сервер должен убедиться, что у клиента есть разрешение на выполнение над ресурсом запрошенных операций. Так, если пользователь на удаленной машине пытается удалить файл с сетевого диска NTFS, сервер, экспортирующий этот сетевой ресурс, должен проверить, имеет ли пользователь право удалить данный файл. Казалось бы, в таком случае сервер должен запросить учетную запись пользователя и SID-идентификаторы группы, а также просканировать атрибуты защиты файла. Ho этот процесс труден для программирования, подвержен ошибкам и не позволяет обеспечить поддержку новых функций защиты. Поэтому Windows в таких ситуациях предоставляет серверу сервисы олицетворения.

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

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

За поддержку олицетворения в Windows отвечает несколько механизмов. Если сервер взаимодействует с клиентом через именованный канал, он может вызвать Windows-функцию ImpersonateNamedPipeClient и тем самым сообщить SRM о том, что ему нужно подменить собой пользователя на другом конце канала. Если сервер взаимодействует с клиентом через DDE (Dynamic Data Exchange) или RPC, то выдает аналогичный запрос на олицетворение через DdeImpersonateClient или RpcImpersonateClient. Поток может создать маркер олицетворения просто как копию маркера своего процесса, вызвав функцию ImpersonateSelf. Для блокировки каких-то SID или привилегий поток может потом изменить полученный маркер олицетворения. Наконец, пакет SSPI (Security Support Provider Interface) может олицетворять своих клиентов через ImpersonateSecurityContext. SSPI реализует модель сетевой защиты вроде LAN Manager версии 2 или Kerberos.

После того как серверный поток завершает выполнение своей задачи, он возвращает себе прежний профиль защиты. Эти формы олицетворения удобны для выполнения определенных операций по запросу клиента и для корректного аудита обращений к объектам. (Например, генерируемые данные аудита сообщают идентификацию подменяемого клиента, а не серверного процесса.) Их недостаток в том, что нельзя выполнять всю программу в контексте клиента. Кроме того, маркер олицетворения не дает доступа к сетевым файлам или принтерам, если только они не поддерживают null-сеансы или не используется олицетворение уровня делегирования (delegation-level impersonation), причем удостоверения защиты достаточны для аутентификации на удаленном компьютере. (Null-сеанс создается при анонимном входе.)

Если все приложение должно выполняться в контексте защиты клиента или получать доступ к сетевым ресурсам, клиент должен быть зарегистрирован в системе. Для этого предназначена Windows-функция LogonUser, которая принимает в качестве параметров имя учетной записи, пароль, имя домена или компьютера, тип входа (интерактивный, пакетный или сервисный) и провайдер входа (logon provider), а возвращает основной маркер. Серверный поток принимает маркер в виде маркера олицетворения, либо сервер запускает программу, основной маркер которой включает удостоверения клиента. C точки зрения защиты, процесс, создаваемый с применением маркера, который возвращается при интерактивном входе через Logon-User, например API-функцией CreateProcessAsUser, выглядит как программа, запущенная пользователем при интерактивном входе в систему. Недостаток этого подхода в том, что серверу приходится получать имя и пароль по учетной записи пользователя. Если сервер передает эту информацию по сети, он должен надежно шифровать ее, чтобы избежать получения имени и пароля злоумышленником, перехватывающим сетевой трафик.

Windows не позволяет серверам подменять клиенты без их ведома. Клиентский процесс может ограничить уровень олицетворения серверным процессом, сообщив при соединении с ним требуемый SQOS (Security Quality of Service). Процесс может указывать флаги SECURITY_ANONYMOUS, SECURITY_IDENTIFICATION, SECURITYIMPERSONATION и SECURITYDELEGATION при вызове Windows-функции CreateFile. Каждый уровень позволяет серверу выполнять различный набор операций относительно контекста защиты клиента:

• SecurityAnonymous — самый ограниченный уровень; сервер не может олицетворять или идентифицировать клиент;

• SecurityIdentification — сервер может получать SID и привилегии клиента, но не получает право на олицетворение клиента;

• SecurityImpersonation — сервер может идентифицировать и олицетворять клиент в локальной системе;

• SecurityDelegation — наименее ограниченный уровень. Позволяет серверу олицетворять клиент в локальных и удаленных системах. Windows NT 4 и более ранние версии лишь частично поддерживают этот уровень олицетворения.

Если клиент не устанавливает уровень олицетворения, Windows по умолчанию выбирает SecurityImpersonation. Функция CreateFile также принимает модификаторы SECURITY_EFFECTIVE_ONLY и SECURITY_CONTEXT_TRACKING.

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

Ограниченные маркеры

Ограниченный маркер (restricted token) создается на базе основного или олицетворяющего с помощью функции CreateRestrictedToken и является его копией, в которую можно внести следующие изменения:

• удалить некоторые элементы из таблицы привилегий маркера;

• пометить SID-идентификаторы маркера атрибутом проверки только на запрет (deny-only);

• пометить SID-идентификаторы маркера как ограниченные.

Поведение SID с атрибутом проверки только на запрет (deny-only SID) и ограниченных SID (restricted SID) кратко поясняется в следующих разделах. Ограниченные маркеры удобны, когда приложение подменяет клиент при выполнении небезопасного кода. B ограниченном маркере может, например, отсутствовать привилегия на перезагрузку системы, что не позволит коду, выполняемому в контексте защиты ограниченного маркера, перезагрузить систему.

ЭКСПЕРИМЕНТ: просмотр ограниченных маркеров

B Windows XP или Windows Server 2003 можно заставить Explorer создать процесс с ограниченным маркером по следующей процедуре.

1. Создайте на рабочем столе ярлык для \Windows\Notepad.exe.

2. Отредактируйте свойства ярлыка и установите флажок Run With Different Credentials (Запускать с другими учетными данными). Заметьте: в описании под этим флажком говорится о том, что вы можете запускать программу от своего имени, в то же время защищая компьютер от несанкционированных действий данной программы*.

3. Закройте окно свойств и запустите программу двойным щелчком ее ярлыка.

4. Согласитесь с параметрами по умолчанию для выполнения под текущей учетной записью и защиты компьютера от несанкционированных действий этой программы.

5. Запустите Process Explorer и просмотрите содержимое вкладки Security для свойств запущенного вами процесса Notepad. Заметьте, что маркер содержит ограниченные SID и SID с атрибутом проверки только на запрет, а также что у него лишь одна привилегия. Свойства в левой части окна, показанного на следующей иллюстрации, относятся к Notepad, выполняемому с неограниченным маркером, а свойства в правой части окна — к его экземпляру, запущенному по описанной процедуре.

* B русской версии Windows XP ошибочно говорится о защите от несанкционированных действий других программ. — Прим. перев.

Ограниченный маркер дает несколько побочных эффектов.

• Удаляются все привилегии, кроме SeChangeNotifyPrivilege.

• Любые SID администраторов или пользователей с правами администраторов помечаются как Deny-Only (проверка только на запрет). Такой SID удаляет права доступа к любым ресурсам, доступ к которым для администраторов запрещен соответствующим АСЕ, но в ином случае был бы замещен АСЕ, ранее выданным группе администраторов через дескриптор защиты.

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

• SID учетной записи, под которой вы запустили процесс, не включается в список как ограниченный. To есть процесс не сможет обращаться к объектам, доступ к которым разрешен по вашей учетной записи, но не по учетным записям любых групп, в которые вы входите. Например, у каталога вашего профиля в \Documents and Settings имеется дескриптор защиты по умолчанию, разрешающий доступ по вашей учетной записи, по учетной записи группы администраторов и по учетной записи System. Попытавшись открыть этот каталог из Notepad, запущенного так, как было показано ранее, вы не получите к нему доступа, потому что вторая, внутренняя проверка прав доступа, выполняемая с применением ограниченных SID, закончится неудачей — SID пользователя нет в списке ограниченных SID.

Дескрипторы защиты и управление доступом

Маркеры, которые идентифицируют удостоверения пользователя, являются лишь частью выражения, описывающего защиту объектов. Другая его часть — информация о защите, сопоставленная с объектом и указывающая, кому и какие действия разрешено выполнять над объектом. Структура данных, хранящая эту информацию, называется дескриптором защиты (security descriptor). Дескриптор защиты включает следующие атрибуты.

• Номер версии Версия модели защиты SRM, использованной для создания дескриптора.

• Флаги Необязательные модификаторы, определяющие поведение или характеристики дескриптора. Пример — флаг SE_DACL_PROTECTED, который запрещает наследование дескриптором параметров защиты от другого объекта.

• SID владельца Идентификатор защиты владельца.

• SID группы Идентификатор защиты основной группы для данного объекта (используется только POSIX).

• Список управления избирательным доступом (discretionary access-control list, DACL) Указывает, кто может получать доступ к объекту и какие виды доступа.

• Системный список управления доступом (system access-control list, SACL) Указывает, какие операции и каких пользователей должны регистрироваться в журнале аудита безопасности.

Список управления доступом (access-control list, ACL) состоит из заголовка и может содержать элементы (access-control entries, АСЕ). Существует два типа ACL: DACL и SACL. B DACL каждый ACE содержит SID и маску доступа (а также набор флагов), причем ACE могут быть четырех типов: «доступ разрешен» (access allowed), «доступ отклонен» (access denied), «разрешенный объект» (allowed-object) и «запрещенный объект» (denied-object). Как вы, наверное, и подумали, первый тип ACE разрешает пользователю доступ к объекту, а второй — отказывает в предоставлении прав, указанных в маске доступа.

Разница между ACE типа «разрешенный объект» и «доступ разрешен», а также между ACE типа «запрещенный объект» и «доступ отклонен» заключается в том, что эти типы используются только в Active Directory. ACE этих типов имеют поле глобально уникального идентификатора (globally unique identifier, GUID), которое сообщает, что данный ACE применим только к определенным объектам или под объектам (с GUID-идентификаторами). Кроме того, необязательный GUID указывает, что тип дочернего объекта наследует ACE при его (объекта) создании в контейнере Active Directory, к которому применен АСЕ. (GUID — это гарантированно уникальный 128-битный идентификатор.)

За счет аккумуляции прав доступа, сопоставленных с индивидуальными АСЕ, формируется набор прав, предоставляемых ACL-списком. Если в дескрипторе защиты нет DACL (DACL = null), любой пользователь получает полный доступ к объекту. Если DACL пуст (т. е. в нем нет АСЕ), доступа к объекту не получает никто.

АСЕ, используемые в DACL, также имеют набор флагов, контролирующих и определяющих характеристики АСЕ, связанные с наследованием. Некоторые пространства имен объектов содержат объекты-контейнеры и объекты-листы (leaf objects). Контейнер может включать другие контейнеры и листы, которые являются его дочерними объектами. Примеры контейнеров — каталоги в пространстве имен файловой системы и разделы в пространстве имен реестра. Отдельные флаги контролируют, как ACE применяется к дочерним объектам контейнера, сопоставленного с этим АСЕ. Часть правил наследования ACE представлена в таблице 8–3 (полный список см. в Platform SDK).

SACL состоит из ACE двух типов: системного аудита (system audit ACE) и объекта системного аудита (system audit-object АСЕ). Эти ACE определяют, какие операции, выполняемые над объектами конкретными пользователями или группами, подлежат аудиту. Информация аудита хранится в системном журнале аудита. Аудиту могут подлежать как успешные, так и неудачные операции. Как и специфические для объектов ACE из DACL, ACE объектов системного аудита содержат GUID, указывающий типы объектов или под-объектов, к которым применим данный АСЕ, и необязательный GUID, контролирующий передачу ACE дочерним объектам конкретных типов. При SACL, равном null, аудит объекта не ведется. (Об аудите безопасности мы расскажем позже.) Флаги наследования, применимые к DACL АСЕ, применимы к ACE системного аудита и объектов системного аудита.

Упрощенная схема объекта «файл» и его DACL представлена на рис. 8–4.

Как показано на рис. 8–4, первый ACE позволяет USERl читать файл. Второй ACE разрешает членам группы TEAM1 читать и записывать файл. Третий ACE предоставляет доступ к файлу для выполнения всем пользователям.

ЭКСПЕРИМЕНТ: просмотр дескриптора защиты

Управляя дескрипторами защиты своих объектов, большинство подсистем исполнительной системы полагаются на функции защиты по умолчанию, предоставляемые диспетчером объектов. Эти функции сохраняют дескрипторы защиты для таких объектов, используя указатель дескриптора защиты (security descriptor pointer). Например, защитой по умолчанию пользуется диспетчер процессов, поэтому диспетчер объектов хранит дескрипторы защиты процессов и потоков в заголовках объектов «процесс» и «поток» соответственно. Указатель дескриптора защиты также применяется для хранения дескрипторов защиты событий, мьютексов и семафоров. Для просмотра дескрипторов защиты этих объектов можно использовать отладчик ядра, но сначала вы должны найти заголовок нужного объекта. Вся эта процедура поясняется ниже.

1. Запустите отладчик ядра.

2. Введите !process 0 0, чтобы увидеть адрес Winlogon. (Если в системе активно более одного сеанса Terminal Server, выполняется несколько экземпляров Winlogon.) Затем вновь введите !process, но укажите адрес одного из процессов Winlogon:

3. Введите !object и адрес, следующий за словом PROCESS в выводе предыдущей команды. Это позволит увидеть структуру данных объекта:

4. Введите dt _OBJECT_HEADER и адрес поля заголовка объекта из вывода предыдущей команды для просмотра структуры данных заголовка объекта, включая значение указателя дескриптора защиты:

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

Дескриптор защиты содержит два ACE типа «доступ разрешен», причем один из них указывает учетную запись администратора (ее можно распознать по RID, равному 500), а другой — учетную запись System (которая всегда выглядит как S-l-5-18). Без декодирования битов, установленных в масках доступа в ACE и определения того, каким типам доступа к процессам они соответствуют, очень трудно сказать, какими правами доступа к объекту «процесс» для Winlogon обладает каждая из этих учетных записей. Однако, если вы сделаете это, используя заголовочные файлы из SDK, то обнаружите, что обе учетные записи имеют полные права доступа.

Присвоение ACL

Чтобы определить, какой DACL следует назначить новому объекту, система защиты использует первое применимое правило из следующего списка.

1. Если вызывающий поток явно предоставляет дескриптор защиты при создании объекта, то система защиты применяет его к объекту. Если у объекта есть имя и он находится в объекте-контейнере (например, именованное событие в каталоге \BaseNamedObjects пространства имен диспетчера объектов), система объединяет в DACL все наследуемые ACE (АСЕ, которые могут быть переданы от контейнера объекта), но только в том случае, если в дескрипторе защиты не установлен флаг SE_DACL_PROTECTED, запрещающий наследование.

2. Если вызывающий поток не предоставляет дескриптор защиты и объекту присваивается имя, система защиты ищет этот дескриптор в контейнере, в котором хранится имя нового объекта. Некоторые ACE каталога объектов могут быть помечены как наследуемые. Это означает, что они должны применяться к новым объектам, создаваемым в данном каталоге. При наличии наследуемых ACE система защиты формирует из них ACL, назначаемый новому объекту. (B АСЕ, наследуемых только объектами-контейнерами, устанавливаются отдельные флаги.)

3. Если дескриптор защиты не определен и объект не наследует какие-либо АСЕ, система защиты извлекает DACL по умолчанию из маркера доступа вызывающего потока и применяет его к новому объекту. B некоторые подсистемы Windows (например, службы, LSA и SAM-объекты) «зашиты» свои DACL, назначаемые ими объектам при создании.

4. Если дескриптор защиты не определен и нет ни наследуемых АСЕ, ни DACL по умолчанию, система создает объект без DACL, что открывает полный доступ к нему любым пользователям и группам. Это правило идентично третьему, если маркер содержит нулевой DACL по умолчанию. Правила, используемые системой при назначении SACL новому объекту,

аналогичны правилам присвоения DACL за двумя исключениями. Первое заключается в том, что наследуемые ACE системного аудита не передаются объектам с дескрипторами защиты, помеченными флагом SE_SACL_PROTEC-TED (DACL точно так же защищается флагом SE_DACL_PROTECTED). Второе исключение: если ACE системного аудита не определены и наследуемого SACL нет, то SACL вообще не присваивается объекту (в маркерах нет SACL по умолчанию).

Когда к контейнеру применяется новый дескриптор защиты, содержащий наследуемые АСЕ, система автоматически передает их в дескрипторы защиты дочерних объектов. (Заметьте, что DACL дескриптора защиты не принимает наследуемые DACL АСЕ, если установлен флаг SE_DACL_PROTECTED, а его SACL не наследует SACL АСЕ, если установлен флаг SE_SACL_PROTECTED.) B соответствии с порядком слияния наследуемых ACE с дескриптором защиты дочернего объекта любые АСЕ, явно примененные к ACL, размещаются до АСЕ, унаследованных объектом. Система использует следующие правила передачи наследуемых АСЕ.

• Если дочерний объект без DACL наследует АСЕ, он получает DACL, содержащий лишь унаследованные АСЕ.

• Если дочерний объект с пустым DACL наследует АСЕ, он также получает DACL, содержащий лишь унаследованные АСЕ.

• Только для объектов в Active Directory: если наследуемый ACE удаляется из родительского объекта, все копии этого ACE автоматически удаляются из всех дочерних объектов.

• Только для объектов в Active Directory: если из DACL дочернего объекта автоматически удалены все АСЕ, у дочернего объекта остается пустой DACL.

Как вы вскоре убедитесь, порядок ACE в ACL является важным аспектом модели защиты Windows.

ПРИМЕЧАНИЕ Как правило, наследование не поддерживается напрямую такими хранилищами объектов, как файловые системы, реестр или Active Directory. Функции Windows API, поддерживающие наследование, в том числе SetSecurityInfo и SetNamedSecurityInfo, реализуют наследование вызовом соответствующих функций из DLL поддержки наследования атрибутов защиты (\Windows\System32\Ntmarta.Dll), которым известно, как устроены эти хранилища объектов.

Определение прав доступа

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

• сравнивающий запрошенные права с максимально возможными для данного объекта и экспортируемый в пользовательский режим в виде Windows-функции GetEffectiveRightsFromAcl\

• проверяющий наличие конкретных прав доступа и активизируемый через Windows-функцию AccessCheck или AccessCheckByType. Первый алгоритм проверяет элементы DACL следующим образом.

1. B отсутствие DACL (DACL = null) объект является незащищенным, и система защиты предоставляет к нему полный доступ.

2. Если у вызывающего потока имеется привилегия на захват объекта во владение (take-ownership privilege), система защиты предоставляет владельцу право на доступ для записи (write-owner access) до анализа DACL (что такое привилегия захвата объекта во владение и право владельца на доступ для записи, мы поясним чуть позже).

3. Если вызывающий поток является владельцем объекта, ему предоставляются права управления чтением (read-control access) и доступа к DACL для записи (write-DACL access).

4. Из маски предоставленных прав доступа удаляется маска доступа каждого ACE типа «доступ отклонен», SID которого совпадает с SID маркера доступа вызывающего потока.

5. K маске предоставленных прав доступа добавляется маска доступа каждого ACE типа «доступ разрешен», SID которого совпадает с SID маркера доступа вызывающего потока (исключение составляют права доступа, в предоставлении которых уже отказано).

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

Все сказанное применимо лишь к той разновидности алгоритма, которая работает в режиме ядра. Его Windows-версия, реализованная функцией GetEffectiveRigbtsFromAcl, отличается отсутствием шага 2, а также тем, что вместо маркера доступа она рассматривает SID единственного пользователя или группы.

Второй алгоритм проверяет, можно ли удовлетворить конкретный запрос на доступ, исходя из маркера доступа вызывающего потока. У каждой Windows-функции открытия защищенных объектов есть параметр, указывающий желательную маску доступа — последний элемент выражения, описывающего защиту объектов. Чтобы определить, имеет ли вызывающий поток право на доступ к защищенному объекту, выполняются следующие операции.

1. B отсутствие DACL (DACL = null) объект является незащищенным, и система защиты предоставляет к нему запрошенный тип доступа.

2. Если у вызывающего потока имеется привилегия на захват объекта во владение, система защиты предоставляет владельцу право на доступ для записи, а затем анализирует DACL. Однако, если такой поток запросил только доступ владельца для записи, система защиты предоставляет этот тип доступа и не просматривает DACL.

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

4. Просматриваются все ACE в DACL — от первого к последнему. Обработка ACE выполняется при одном из следующих условий:

a. SID в ACE типа «доступ отклонен» совпадает с незаблокированным SID (SID могут быть незаблокированными и заблокированными) или SID с атрибутом проверки только на запрет в маркере доступа вызывающего потока;

b. SID в ACE типа «доступ разрешен» совпадает с незаблокированным SID в маркере доступа вызывающего потока, и этот SID не имеет атрибута проверки только на запрет;

c. Идет уже второй проход поиска в дескрипторе ограниченных SID, и SID в ACE совпадает с ограниченным SID в маркере доступа вызывающего потока.

5. B случае ACE типа «доступ разрешен» предоставляются запрошенные права из маски доступа АСЕ; проверка считается успешной, если предоставляются все запрошенные права. Доступ к объекту не предоставляется в случае ACE типа «доступ отклонен» и отказа в предоставлении какого-либо из запрошенных прав.

6. Если достигнут конец DACL и некоторые из запрошенных прав доступа еще не предоставлены, доступ к объекту запрещается.

7. Если все права доступа предоставлены, но в маркере доступа вызывающего потока имеется хотя бы один ограниченный SID, то система повторно сканирует DACL в поисках АСЕ, маски доступа которых соответствуют набору запрошенных прав доступа. При этом также идет поиск АСЕ, SID которых совпадает с любым из ограниченных SID вызывающего потока. Поток получает доступ к объекту, если запрошенные права доступа предоставлялись после каждого прохода по DACL.

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

Более старые Windows-функции вроде AddAccessAllowedAce добавляли ACE в конец DACL, что нежелательно. Таким образом, до появления Windows 2000 большинство Windows-приложений были вынуждены создавать DACL вручную, помещая запрещающие ACE в начало списка. Несколько функций Windows, например SetSecurityInfo и SetNamedSecurityInfo, используют предпочтительный порядок АСЕ: запрещающие ACE предшествуют разрешающим. Заметьте, что эти функции вызываются при редактировании, например, прав доступа к NTFS-файлам и разделам реестра. SetSecurityInfo и SetNamedSecurityInfo также применяют правила наследования ACE к дескриптору защиты, для операций над которым они вызываются.

Ha рис. 8–5 показан пример проверки прав доступа, демонстрирующий, насколько важен порядок АСЕ. B этом примере пользователю отказано в доступе к файлу, хотя ACE в DACL объекта предоставляет такое право (в силу принадлежности пользователя к группе Writers). Это вызвано тем, что запрещающий ACE предшествует разрешающему.

Маркер доступа

Пользователь: DaveC

Как уже говорилось, обработка DACL системой защиты при каждом использовании описателя процессом была бы неэффективной, поэтому SRM проверяет права доступа только при открытии описателя, а не при каждом его использовании. Так что, если процесс один раз успешно открыл описатель, система защиты не может аннулировать предоставленные при этом права доступа — даже когда DACL объекта изменяется. Учтите и вот еще что: поскольку код режима ядра обращается к объектам по указателям, а не по описателям, при использовании объектов операционной системой права доступа не проверяются. Иначе говоря, исполнительная система полностью доверяет себе в смысле защиты.

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

Будьте осторожны при использовании GUI-средств изменения параметров защиты

Модифицируя с помощью GUI-средств параметры защиты объектов «файл», «реестр», Active Directory или других защищаемых объектов, имейте в виду, что основное диалоговое окно безопасности создает потенциально неверное представление о защите, применяемой для объекта. B верхней части этого окна в алфавитном порядке показываются группы и пользователи, чьи ACE имеются в ACL данного объекта. Если вы выдадите Full Control группе Administrators и запретите его группе Everyone, то, судя по алфавитному списку, можете подумать, будто ACE типа «доступ разрешен» для группы Administrators предшествует ACE типа «доступ отклонен» для группы Everyone. Однако, как мы уже говорили, средства редактирования, применяя ACL к объекту, помещают запрещающие ACE перед разрешающими.

Ha вкладке Permissions (Разрешения) диалогового окна Advanced Security Settings (Дополнительные параметры безопасности) показывается порядок ACE в DACL. Однако даже это диалоговое окно может ввести в заблуждение, так как в сложном DACL за запрещающими ACE для различных видов доступа могут быть расположены разрешающие ACE для других типов доступа.

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

AuthZ API

Auth2 API, впервые введенный в Windows XP, реализует ту же модель защиты, что и Security Reference Monitor (монитор состояния защиты), но исключительно для пользовательского режима; все функции AuthZ API находятся в библиотеке \Windows\System32\Authz.Dll. Это позволяет приложениям, нуждающимся в защите своих закрытых объектов (вроде таблиц базы данных), задействовать Windows-модель защиты без издержек, связанных с переходами из пользовательского режима в режим ядра, которые были бы неизбежны при использовании Security Reference Monitor.

AuthZ API оперирует стандартными структурами дескриптора защиты, SID и привилегиями. Вместо применения маркеров для представления клиентов, AuthZ использует AUTHZ_CLIENT_CONTEXT. AuthZ включает эквиваленты всех функций проверки прав доступа и защиты Windows; например AutbzAccessCbeck — это AuthZ-версия Windows-функции AccessCbeck, которая вызывает функцию SeAccessCbeck, принадлежащую Security Reference Monitor.

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

AuthZ полностью документирован в Platform SDK.

Права и привилегии учетных записей

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

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

Системный администратор назначает привилегии группам и учетным записям с помощью таких инструментов, как ММС-оснастка Active Directory Users and Groups (Active Directory — пользователи и группы) или редактора локальной политики безопасности (Local Security Policy Editor)*. Запустить этот редактор можно из папки Administrative Tools (Администрирование). Ha рис. 8–6 показана конфигурация User Rights Assignment (Назначение прав пользователя) редактора локальной политики безопасности, при которой в правой части окна выводится полный список привилегий и прав (учетных записей), доступных в Windows Server 2003. Заметьте, что этот редактор не различает привилегии и права учетных записей. Ho вы можете сделать это сами, поскольку любое право, в названии которого встречается слово «logon» («вход»), на самом деле является привилегией.

* B русской версии Windows XP окно этого редактора называется «Локальные параметры безопасности». — Прим. перев.

Права учетной записи

Права учетной записи не вводятся в действие монитором состояния защиты (Security Reference Monitor, SRM) и не хранятся в маркерах. За вход отвечает функция LsaLogonUser. B частности, WinLogon вызывает API-функцию LogonUser, когда пользователь интерактивно входит в систему, aLogonUser обращается KLsaLogonUser. Эта функция принимает параметр, указывающий тип выполняемого входа, который может быть интерактивным, сетевым, пакетным, сервисным, через службу терминала или для разблокировки (unlock).

B ответ на запросы входа служба локальной безопасности (Local Security Authority, LSA) извлекает назначенные пользователю права учетной записи из своей базы данных; эта операция выполняется при попытке пользователя войти в систему LSA сверяет тип входа с правами учетной записи и по результатам этой проверки отклоняет попытку входа, если у учетной записи нет права, разрешающего данный тип входа, или, напротив, есть право, которое запрещает данный тип входа. Права пользователей, определенные в Windows, перечислены в таблице 8–4.

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

Привилегии

Число привилегий, определяемых в операционной системе, со временем выросло. B отличие от прав пользователей, которые вводятся в действие в одном месте службой LSA, разные привилегии определяются разными компонентами и ими же применяются. Скажем, привилегия отладки, позволяющая процессу обходить проверки прав доступа при открытии описателя другого процесса через API-функцию OpenProcess, проверяется диспетчером процессов. Полный список привилегий приведен в таблице 8–5.

Компонент, которому нужно проверить маркер на наличие некоей привилегии, обращается к API-функции PrivilegeCheck или LsaEnumerateAccountRights, если он выполняется в пользовательском режиме, либо к SeSingle-PrivilegeCbeck или SePrivilegeCbeck, если он работает в режиме ядра. API-функции, работающие с привилегиями, ничего не знают о правах учетных записей, но API-функциям, оперирующим с правами, привилегии известны.

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

ЭКСПЕРИМЕНТ: наблюдение за включением привилегии

Следующая процедура позволит увидеть, как апплет Date and Time (Дата и время) из Control Panel включает привилегию SeSystemTime-Privilege, исходя из того, что его интерфейс будет использован для изменения даты или времени на компьютере.

1. Войдите в систему под учетной записью, имеющей право «Change the system time» (Изменение системного времени); такая учетная запись обычно входит в группу администраторов или пользователей с правами администраторов.

2. Запустите Process Explorer и выберите для частоты обновления значение Paused.

3. Откройте вкладку Security в окне свойств какого-либо процесса, например Explorer. Вы должны увидеть, что привилегия SeChange-SystemTimePrivilege отключена.

4. Запустите апплет Date and Time из Control Panel и обновите окно Process Explorer. B списке появится новый процесс Rundll, выделенный зеленым цветом.

5. Откройте окно свойств для процесса Rundll (дважды щелкнув имя этого процесса) и убедитесь, что командная строка содержит текст «Timedate.Cpl». Наличие этого аргумента сообщает Rundll (хост-процессу Control Panel DLL) загрузить DLL, реализующую UI, который позволяет изменять дату и время.

6. Перейдите на вкладку Security в окне свойств процесса Rundll и вы увидите, что привилегия SeSystemTimePrivilege включена.

ЭКСПЕРИМЕНТ: привилегия Bypass Traverse Checking

Если вы являетесь системным администратором, то должны знать о привилегии Bypass Traverse Checking (Обход перекрестной проверки)* (ее внутреннее название — SeNotifyPrivilege) и о том, какие последствия влечет за собой ее включение. Этот эксперимент демонстрирует, что непонимание ее поведения может привести к серьезному нарушению безопасности.

1. Создайте папку, а в ней — новый текстовый файл с каким-нибудь текстом.

2. Перейдите в Explorer к новому файлу и откройте вкладку Security (Безопасность) в его окне свойств. Щелкните кнопку Advanced (Дополнительно) и сбросьте флажок, управляющий наследованием. Выберите Сору (Копировать), когда появится запрос с предложением удалить или скопировать унаследованные разрешения.

3. Далее сделайте так, чтобы по вашей учетной записи нельзя было получить доступ к этой новой папке. Для этого выберите свою учетную запись и в списке разрешений выберите все флажки типа Deny (отклонить или запретить).

4. Запустите Notepad и попробуйте через его UI перейти в новую папку. Вы не сможете этого сделать.

5. B поле File Name (Имя файла) диалогового окна Open (Открыть) введите полный путь к новому файлу. Файл должен открыться. Если в вашей учетной записи нет привилегии Bypass Traverse Checking, NTFS будет проверять права доступа к каждому каталогу в пути к файлу, когда вы попытаетесь открыть этот файл. И только в таком случае вам будет отказано в доступе к данному файлу.

* Так эта привилегия называется в русской версии Windows XP, но на самом деле никакой перекрестной проверки нет — проверяются промежуточные каталоги в пути к файлу. Поэтому такую привилегию следовало бы назвать «Обход промежуточных проверок». — Прим. перев.

Суперпривилегии

Несколько привилегий дают настолько широкие права, что пользователя, которому они назначаются, называют «суперпользователем» — он получает полный контроль над компьютером. Эти привилегии позволяют получать неавторизованный доступ к закрытым ресурсам и выполнять любые операции. Ho мы уделим основное внимание применению привилегии на запуск кода, который выдает привилегии, изначально не назначавшиеся пользователю, и при этом не будем забывать, что это может быть использовано для выполнения любой операции на локальном компьютере. B этом разделе перечисляются такие привилегии и рассматриваются способы их применения. Прочие привилегии вроде Lock Pages In Physical Memory (Закрепление страниц в памяти) можно использовать для атак типа «отказ в обслуживании», но мы не станем их обсуждать.

• Debug programs (Отладка программ) Пользователь с этой привилегией может открыть любой процесс в системе независимо от его дескриптора защиты. Например, располагая такой привилегией, можно запустить свою программу, которая открывает процесс LSASS, копирует в ее адресное пространство исполняемый код, а затем внедряет поток с помощью API-функции CreateRemoteThread для выполнения внедренного кода в более привилегированном контексте защиты. Этот код мог бы выдавать пользователю дополнительные привилегии и расширять его членство в группах.

• Take ownership (Смена владельца)* Эта привилегия позволяет ее обладателю сменить владельца любого защищаемого объекта, просто вписав свой SID в поле владельца в дескрипторе защиты объекта. Вспомните, что владелец всегда получает разрешение на чтение и модификацию DACL дескриптора защиты, поэтому процесс с такой привилегией мог бы изменить DACL, чтобы разрешить себе полный доступ к объекту, а затем закрыть объект и вновь открыть его с правами полного доступа. Это позволило бы увидеть любые конфиденциальные данные и даже подменить системные файлы, выполняемые при обычных системных операциях, например LSASS, своими программами, которые расширяют привилегии некоего пользователя.

• Restore files and directories (Восстановление файлов и каталогов)

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

• Load and unload device drivers (Загрузка и выгрузка драйверов устройств) Злоумышленник мог бы воспользоваться этой привилегией для загрузки драйвера устройства в систему. Такие драйверы считаются доверяемыми частями операционной системы, которые выполняются под системной учетной записью, поэтому драйвер мог бы запускать привилегированные программы, назначающие пользователю-злоумышленнику другие права.

• B русской версии Windows XP эта привилегия называется «Овладение файлами или иными объектами». — Прим. перев.

• Create a token object (Создание маркерного объекта) Эта привилегия позволяет создавать объекты «маркеры», представляющие произвольные учетные записи с членством в любых группах и любыми разрешениями.

• Act as part of operating system (Работа в режиме операционной системы) Эта привилегия проверяется функцией LsaRegisterLogonProcess, вызываемой процессом для установления доверяемого соединения с LSASS. Злоумышленник с такой привилегией может установить доверяемое соединение с LSASS, а затем вызвать LsaLogonUser — функцию, используемую для создания новых сеансов входа. LsaLogonUser требует указания действительных имени и пароля пользователя и принимает необязательный список SID, добавляемый к начальному маркеру, который создается для нового сеанса входа. B итоге можно было бы использовать свои имя и пароль для создания нового сеанса входа, в маркер которого включены SID более привилегированных групп или пользователей. Заметьте, что расширенные привилегии не распространяются за границы локальной системы в сети, потому что любое взаимодействие с другим компьютером требует аутентификации контроллером домена и применения доменных паролей. A доменные пароли не хранятся на компьютерах (даже в зашифрованном виде) и поэтому недоступны злонамеренному коду.

Аудит безопасности

События аудита может генерировать диспетчер объектов в результате проверки прав доступа. Их могут генерировать и непосредственно Windows-функции, доступные пользовательским приложениям. Это же право, разумеется, есть и у кода режима ядра. C аудитом связаны две привилегии: SeSecu-rityPrivilege и SeAuditPrivilege. Для управления журналом событий безопасности, а также для просмотра и изменения SACL объектов процесс должен обладать привилегией SeSecurityPrivilege. Однако процесс, вызывающий системные сервисы аудита, должен обладать привилегией SeAuditPrivilege, чтобы успешно сгенерировать запись аудита в этом журнале.

Решения об аудите конкретного типа событий безопасности принимаются в соответствии с политикой аудита локальной системы. Политика аудита, также называемая локальной политикой безопасности (local security policy), является частью политики безопасности, поддерживаемой LSASS в локальной системе, и настраивается с помощью редактора локальной политики безопасности (рис. 8–7).

При инициализации системы и изменении политики LSASS посылает SRM сообщения, информирующие его о текущей политике аудита. LSASS отвечает за прием записей аудита, генерируемых на основе событий аудита от SRM, их редактирование и передачу Event Logger (регистратору событий). Эти записи посылает именно LSASS (а не SRM), так как он добавляет в них сопутствующие подробности, например информацию, нужную для более полной идентификации процесса, по отношению к которому проводится аудит.

Рис. 8–7. Конфигурация Audit Policy редактора локальной политики безопасности

SRM посылает записи аудита LSASS через свое LPC-соединение. После этого Event Logger заносит записи в журнал безопасности. B дополнение к записям аудита, передаваемым SRM, LSASS и SAM тоже генерируют записи аудита, которые LSASS пересылает непосредственно Event Logger; кроме того, AuthZ API позволяет приложениям генерировать записи аудита, определенные этими приложениями. Вся эта схема представлена на рис. 8–8.

Записи аудита, подлежащие пересылке LSA, помещаются в очередь по мере получения — они не передаются пакетами. Пересылка этих записей осуществляется одним из двух способов. Если запись аудита невелика (меньше максимального размера LPC-сообщения), она посылается как LPC-cooбщение. Записи аудита копируются из адресного пространства SRM в адресное пространство процесса Lsass. Если запись аудита велика, SRM делает ее доступной Lsass через разделяемую память и передает Lsass указатель на нее, используя для этого LPC-сообщение.

Рис. 8–9 обобщает изложенные в этой главе концепции, иллюстрируя базовые структуры защиты процессов и потоков. Обратите внимание на то, что у объектов «процесс» и «поток» имеются ACL, равно как и у самих объектов «маркер доступа». Кроме того, на этой иллюстрации показано, что у потоков 2 и 3 есть маркер олицетворения, тогда как поток 1 по умолчанию использует маркер доступа своего процесса.

Вход в систему

При интерактивном входе в систему (в отличие от входа через сеть) происходит взаимодействие с процессами Winlogon, Lsass, одним или несколькими пакетами аутентификации, а также SAM или Active Directory. Пакеты аутентификации (authentication packages) — это DLL-модули, выполняющие проверки, связанные с аутентификацией. Пакетом аутентификации Windows для интерактивного входа в домен является Kerberos, a MSV1_0 — аналогичным пакетом для интерактивного входа на локальные компьютеры, доменного входа в доверяемые домены под управлением версий Windows, предшествовавших Windows 2000, а также для входа в отсутствие контроллера домена.

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

Winlogon получает имя и пароль пользователя через Graphical Identification and Authentication (GINA) DLL. Стандартная GINA — \Windows\System32\ Msgina.dll. Msgina выводит диалоговое окно для входа в систему. Позволяя заменять Msgina другими GINA-библиотеками, Windows дает возможность менять механизмы идентификации пользователей. Например, сторонний разработчик может создать GINA для поддержки устройства распознавания отпечатков пальцев и для выборки паролей пользователей из зашифрованной базы данных.

Winlogon — единственный процесс, который перехватывает запросы на регистрацию с клавиатуры. Получив имя и пароль пользователя от GINA, Winlogon вызывает LSASS для аутентификации этого пользователя. Если аутентификация прошла успешно, процесс Winlogon активизирует оболочку. Схема взаимодействия между компонентами, участвующими в процессе регистрации, показана на рис. 8-10.

Winlogon не только поддерживает альтернативные GINA, но и может загружать дополнительные DLL провайдеров доступа к сетям, необходимые для вторичной аутентификации. Это позволяет сразу нескольким сетевым провайдерам получать идентификационные и регистрационные данные в процессе обычного входа пользователя в систему. Входя в систему под управлением Windows, пользователь может одновременно аутентифицироваться и на UNIX-сервере. После этого он получит доступ к ресурсам UNIX-сервера с компьютера под управлением Windows без дополнительной аутентификации. Эта функциональность является одной из форм унифицированной регистрации (single sign-on).

Инициализация Winlogon

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

1. Создает и открывает интерактивный объект WindowStation (например, \Windows\WindowStations\WinStaO в пространстве имен диспетчера объектов), представляющий клавиатуру, мышь и монитор. Далее создает дескриптор защиты станции с одним АСЕ, содержащим только системный SID. Этот уникальный дескриптор безопасности гарантирует, что другой процесс получит доступ к рабочей станции, только если Winlogon явно разрешит это.

2. Создает и открывает два объекта «рабочий стол»: для приложений (\Win-dows\WinStaO\Default, также известный как интерактивный рабочий стол) и Winlogon (\Windows\WinStaO\Winlogon, также известный как защищенный рабочий стол). Защита объекта «рабочий стол» Winlogon организуется так, чтобы к нему мог обращаться только Winlogon. Другой объект «рабочий стол» доступен как Winlogon, так и пользователям. Следовательно, пока активен объект «рабочий стол» Winlogon, никакой другой процесс не получает доступа к коду и данным, сопоставленным с этим рабочим столом. Эта функциональность используется Windows для защиты операций, требующих передачи паролей, а также для блокировки и разблокировки рабочего стола.

3. До входа какого-либо пользователя в систему видимым рабочим столом является объект «рабочий стол» Winlogon. После входа нажатие клавиш Ctrl+Alt+Del вызывает переключение объектов «рабочий стол» — с Default на Winlogon. (Это объясняет, почему после нажатия Ctrl+Alt+Del с рабочего стола исчезают все окна и почему они возвращаются, как только закрывается диалоговое окно Windows Security.) Таким образом, SAS всегда активизирует защищенный рабочий стол, контролируемый Winlogon.

4. Устанавливает LPC-соединение с LSASS через LsaAutbenticationPort (вызовом LsaRegisterLogonProcess). Это соединение понадобится для обмена информацией при входе и выходе пользователя из системы и при операциях с паролем.

Далее Winlogon настраивает оконную среду.

5. Инициализирует и регистрирует структуру данных оконного класса, которая сопоставляет процедуру Winlogon с создаваемым ею окном.

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

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

Как реализована SAS

SAS безопасна потому, что никакое приложение не может перехватить комбинацию клавиш Ctrl+Alt+Del или воспрепятствовать его получение Winlogon. Winlogon использует документированную API-функцию RegisterHotKey для резервирования комбинации клавиш Ctrl+Alt+Del, поэтому подсистема ввода Windows, обнаружив эту комбинацию, посылает специальное сообщение окну, создаваемому Winlogon для приема таких уведомлений. Любая зарезервированная комбинация клавиш посылается только тому процессу, который зарезервировал ее, и лишь поток, зарезервировавший данную комбинацию клавиш, может отменить ее регистрацию (через API-функцию UnregisterHotKey), так что троянская программа не в состоянии забрать на себя SAS.

Windows-функция SetWindowsHook позволяет приложению установить процедуру-ловушку, вызываемую при каждом нажатии клавиш еще до обработки какой-либо комбинации, и модифицировать эти клавиши. Однако в коде обработки комбинаций клавиш содержится специальный блок case для Ctrl+Alt+Del, который отключает ловушки, исключая возможность перехвата этой последовательности. Кроме того, если интерактивный рабочий стол блокирован, обрабатываются только комбинации клавиш, принадлежащие Winlogon.

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

Этапы входа пользователя

Регистрация начинается, когда пользователь нажимает комбинацию клавиш SAS (по умолчанию — Ctrl+Alt+Del). После этого Winlogon вызывает GINA, чтобы получить имя и пароль пользователя. Winlogon также создает уникальный локальный SID для этого пользователя и назначает его данному экземпляру объекта «рабочий стол» (который представляет клавиатуру, экран и мышь). Winlogon передает этот SID в LSASS при вызове LsaLogonUser. Если вход пользователя прошел успешно, этот SID будет включен в маркер процесса входа (logon process token) — такой шаг предпринимается для защиты доступа к объекту «рабочий стол». Например, второй вход по той же учетной записи, но в другой системе, не предоставит доступа для записи к объекту «рабочий стол» первого компьютера, так как в его маркере не будет SID, полученного при втором входе.

После ввода имени и пароля пользователя Winlogon получает описатель пакета аутентификации вызовом Lsass-функции LsaLookupAuthenticationPackage. Эти пакеты перечисляются в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Winlogon передает пакету данные входа через LsaLogonUser. После того как пакет аутентифицирует пользователя, Winlogon продолжает процесс входа этого пользователя. Если ни один из пакетов не сообщает об успешной аутентификации, процесс входа прекращается.

Windows использует два стандартных пакета аутентификации при интерактивном входе: Kerberos и MSV1_0. Пакет аутентификации по умолчанию в автономной системе Windows — MSVlO (\Windows\System32\Msvl_0.dll); он реализует протокол LAN Manager 2. LSASS также использует MSVlO на компьютерах, входящих в домен, чтобы аутентифицировать домены и компьютеры под управлением версий Windows до Windows 2000, не способные найти контроллер домена для аутентификации. (Отключенные от сети портативные компьютеры относятся к той же категории.) Пакет аутентификации Kerberos (\Windows\System32\Kerberos.dll) используется на компьютерах, входящих в домены Windows. Этот пакет во взаимодействии со службами Kerberos, выполняемыми на контроллере домена, поддерживает протокол Kerberos версии 5 (ревизии 6). Данный протокол определен в RFC 1510. (Подробнее о стандарте Kerberos см. на сайте Internet Engineering Task Force по ссылке www.ietf.org.)

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

Далее MSVlO сравнивает хэшированный пароль и имя пользователя с теми, которые хранятся в SAM. B случае кэшированного доменного входа MSVlO обращается к кэшированной информации через функции LSASS, отвечающие за сохранение и получение «секретов» из базы данных LSA (куст реестра SECURITY) Если эти данные совпадают, MSVlO генерирует LUID сеанса входа и создает собственно сеанс входа вызовом LSASS. При этом MSVlO сопоставляет данный уникальный идентификатор с сеансом и передает данные, необходимые для того, чтобы в конечном счете создать маркер доступа для пользователя. (Вспомните, что маркер доступа включает SID пользователя, SID групп и назначенные привилегии.)

ПРИМЕЧАНИЕ MSV1_0 не кэширует весь хэш пароля пользователя в реестре, так как это позволило бы любому лицу, имеющему физический доступ к системе, легко скомпрометировать доменную учетную запись пользователя и получить доступ к зашифрованным файлам и к сетевым ресурсам, к которым данный пользователь имеет право обращаться. Поэтому MSV1_0 кэширует лишь половину хэша. Этой половины достаточно для проверки правильности пароля пользователя, но недостаточно для получения доступа к ключам EFS и для аутентификации в домене вместо этого пользователя, так как эти операции требуют полного хэша.

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

Базовая последовательность действий при аутентификации Kerberos в основном та же, что и в случае MSV1_0. Однако в большинстве случаев доменный вход проходит на рабочих станциях или серверах, включенных в домен (а не на контроллере домена), поэтому пакет в процессе аутентификации должен взаимодействовать с ними через сеть. Взаимодействие этого пакета со службой Kerberos на контроллере домена осуществляется через TCP/IP-порт Kerberos (88). Служба Kerberos KeyDistribution Center (\Windows\ System32\Kdcsvc.dll), реализующая протокол аутентификации Kerberos, выполняется в процессе Lsass на контроллерах домена.

После проверки хэшированной информации об имени и пароле пользователя с помощью объектов учетных записей пользователей (user account objects) Active Directory (через сервер Active Directory, \Windows\System32\ Ntdsa.dll) Kdcsvc возвращает доменные удостоверения LSASS, который при успешном входе передает через сеть результат аутентификации и удостоверения пользователя той системе, где выполняется вход.

ПРИМЕЧАНИЕ Приведенное здесь описание аутентификации пакетом Kerberos сильно упрощено, и тем не менее оно иллюстрирует роль различных компонентов в этом процессе. Хотя протокол аутентификации Kerberos играет ключевую роль в обеспечении распределенной защиты доменов в Windows, его детальное рассмотрение выходит за рамки нашей книги.

Как только учетные данные аутентифицированы, LSASS ищет в базе данных локальной политики разрешенный пользователю тип доступа — интерактивный, сетевой, пакетный или сервисный. Если тип запрошенного входа в систему не соответствует разрешенному, вход прекращается. LSASS удаляет только что созданный сеанс входа, освобождая его структуры данных, и сообщает Winlogon о неудаче. Winlogon в свою очередь сообщает об этом пользователю. Если же запрошенный тип входа в систему разрешается, LSASS добавляет любые дополнительные идентификаторы защиты (например, Everyone, Interactive и т. п.). Затем он проверяет в своей базе данных привилегии, назначенные всем идентификаторам данного пользователя, и включает эти привилегии в маркер доступа пользователя.

Собрав всю необходимую информацию, LSASS вызывает исполнительную систему для создания маркера доступа. Исполнительная система создает основной маркер доступа для интерактивного или сервисного сеанса и маркер олицетворения для сетевого сеанса. После успешного создания маркера доступа LSASS дублирует его, создавая описатель, который может быть передан Winlogon, а свой описатель закрывает. Если нужно, проводится аудит операции входа. Ha этом этапе LSASS сообщает Winlogon об успешном входе и возвращает описатель маркера доступа, LUID сеанса входа и информацию из профиля, полученную от пакета аутентификации (если она есть).

ЭКСПЕРИМЕНТ: перечисление активных сеансов входа

Пока существует хотя бы один маркер с данным LUID сеанса входа, Windows считает этот сеанс активным. C помощью утилиты Logon-Sessions (wwwsysintemals.com), которая использует функцию LsaEnu-merateLogonSessions (документированную в Platform SDK), можно перечислить активные сеансы входа:

B информацию, сообщаемую по каждому сеансу, включаются SID и имя пользователя, сопоставленные с данным сеансом, а также пакет аутентификации и время входа. Заметьте, что пакет аутентификации Negotiate, отмеченный в сеансе входа 2, выполняет аутентификацию через Kerberos или NTLM в зависимости от того, какой из них больше подходит для данного запроса на аутентификацию.

LUID для сеанса показывается в строке «Logon Session» блока информации по каждому сеансу, и с помощью утилиты Handle (также доступной с wwwsysinternals.com) можно найти маркеры, представляющие конкретный сеанс входа. Например, чтобы найти маркеры для сеанса входа 8 в предыдущем примере вывода, вы могли бы ввести такую команду:

C: \›handle — a 79da73 43c: Token MARKLAP\Administrator:79da73

Далее Winlogon просматривает параметр реестра HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\Userinit и создает процесс для запуска программ, указанных в строковом значении этого параметра (там могут присутствовать имена нескольких ЕХЕ-файлов, разделенные запятыми). Значение этого параметра по умолчанию приводит к запуску Useri-

nit.exe, который загружает профиль пользователя, а затем создает процесс для запуска программ, перечисленных в HKCU\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\Shell, если такой параметр есть. Если же этого параметра нет, Userinit.exe обращается к параметру HKLM\SOFTWARE\ Microsoft\Windows NT\Current Version\Winlogon\Shell, который по умолчанию задает Explorer.exe. После этого Userinit завершается — вот почему Process Explorer показывает Explorer.exe как процесс, не имеющий предка. Подробнее о том, что происходит в процессе входа, см. в главе 5.

Политики ограниченного использования программ

Злонамеренный код вроде вирусов и червей создает все больше проблем. B Windows XP введен механизм Software Restriction Policies (Политики ограниченного использования программ), который позволяет администраторам контролировать образы и сценарии, выполняемые в их системах. Узел Software Restriction Policies в редакторе локальной политики безопасности (рис. 8-11) служит интерфейсом управления для политик выполнения кода на компьютере, хотя возможны и политики, индивидуальные для пользователей; в последнем случае применяются доменные политики групп.

Узел Software Restriction Policies (Политики ограниченного использования программ) содержит несколько глобальных параметров.

• Параметр Enforcement (Принудительный) определяет, как применяются политики ограничения — к библиотекам вроде DLL, только к пользователям или к пользователям и администраторам.

• Параметр Designated File Types (Назначенные типы файлов) регистрирует расширения файлов, которые считаются исполняемыми.

• Параметр Trusted Publishers (Доверенные издатели) контролирует, кто имеет право решать, каким издателям сертификатов можно доверять.

При настройке параметра для конкретного сценария или образа администратор может указать системе распознавать этот сценарий или образ по его пути, хэшу, зоне Интернета (как определено в Internet Explorer) или по криптографическому сертификату, а также сопоставить его с уровнем безопасности Disallowed (He разрешено) либо Unrestricted (Неограниченный).

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

• Windows-функция CreateProcess (\Windows\System32\Kernel32.dll) пользовательского режима применяет эти политики к исполняемым образам.

• Код загрузки DLL в Ntdll (\Windows\System32\Ntdll.dll) применяет эти политики к DLL.

• Командная оболочка Windows (\Windows\System32\Cmd.exe) применяет эти политики к командным файлам.

• Компоненты Windows Scripting Host, запускающие сценарии, — \Windows\System32\Cscript.exe (для сценариев командной строки), \Windows\ System32\Wscript.exe (для UI-сценариев) и \Windows\System32\Scrobj.dll (для объектов-сценариев) — применяют эти политики к сценариям. Каждый из этих компонентов определяет, действуют ли политики ограничения, по значению параметра реестра HKLM\SOFTWARE\Policies\Micro-soft\Windows\Safer\CodeIdentifiers\TransparentEnabled. Если он равен 1, то политики действуют. Далее каждый из компонентов проверяет, подпадает ли код, который он собирается выполнить, под действие одного из правил, указанных в подразделе раздела CodeIdentifiers, и, если да, следует ли разрешить выполнение. Если ни одно из правил к данному коду не относится, его выполнение зависит от политики по умолчанию, определяемой параметром DefaultLevel в разделе CodeIdentifiers.

Software Restriction Policies — мощное средство для предотвращения запуска неавторизованного кода и сценариев, но только при правильном применении. Если политика по умолчанию не запрещает выполнение, то в образ, который не разрешено запускать в данной системе, можно внести минимальные изменения, и это позволит обойти правило и запустить данный образ.

ЭКСПЕРИМЕНТ: наблюдение за применением политики ограниченного использования программ

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

1. Запустите secpol.msc, чтобы открыть редактор локальной политики безопасности, и перейдите в узел Software Restriction Policies (Политики ограниченного использования программ).

2. Выберите Create New Policies (Создать новые политики) из контекстного меню, если такие политики не определены.

3. Создайте правило, запрещающее путь \Windows\System32\Note-pad.exe.

4. Запустите Regmon и установите включающий фильтр для «Safer» (описание Regmon см. в главе 4).

5. Откройте окно командной строки и попробуйте запустить Notepad. Ваша попытка запуска Notepad должна закончиться появлением сообщения о том, что вам запрещен запуск указанной программы, и Regmon должна показать, как командная оболочка (cmd.exe) запрашивает политики ограничения на локальном компьютере.

Резюме

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

B следующей главе мы обсудим последний из основных компонентов исполнительной системы, описываемых в этой книге, — подсистему ввода-вывода.

ЭКСПЕРИМЕНТ: просмотр структуры данных объекта «файл»

Вы можете просмотреть содержимое этой структуры с помощью команды dt отладчика ядра:

Когда поток открывает файл или простое устройство, диспетчер ввода-вывода возвращает описатель объекта «файл». Рис. 9–7 иллюстрирует, что происходит при открытии файла.

B этом примере С-программа (1) вызывает из стандартной библиотеки функцию fopen, которая в свою очередь вызывает Windows-функцию CreateFile (2). Далее DLL подсистемы Windows (в данном случае — Kernel32.dll) вызывает функцию NtCreateFile из Ntdll.dll (3). Эта функция в Ntdll.dll содержит соответствующие команды, вызывающие переход в режим ядра в диспетчер системных сервисов, который и обращается к настоящей функции NtCreateFile (4) из Ntoskrnl.exe (о диспетчеризации системных сервисов см. главу 3).

ПРИМЕЧАНИЕ Объекты «файл» представляют открытые экземпляры файлов, а не сами файлы. B отличие от UNIX-систем, где используются vnode, в Windows представление файла не определено — системные драйверы Windows определяют свои представления.

Как и другие объекты исполнительной системы, файлы защищаются дескрипторами защиты, которые содержат список управления доступом (ACL). Чтобы выяснить, позволяет ли ACL файла получить процессу доступ того типа, который был запрошен его потоком, диспетчер ввода-вывода обращается к системе защиты. Если да, диспетчер объектов (5,6) разрешает доступ и сопоставляет предоставленные права доступа с описателем файла, возвращаемым потоку. Если этому или другому потоку того же процесса понадобятся дополнительные операции с файлом, не указанные в исходном запросе, ему придется открыть новый описатель, по которому тоже будет проведена проверка прав доступа (подробнее о защите объектов см. главу 8).

ЭКСПЕРИМЕНТ: просмотр описателей устройств

У любого процесса, открывшего описатель какого-либо устройства, в таблице описателей появляется объект «файл», соответствующий открытому экземпляру. Для просмотра таких описателей вполне годится Process Explorer: выберите процесс и пометьте Show Lower Pane в меню View и Handles в подменю Lower Pane View меню View. Отсортируйте по столбцу Туре и прокрутите содержимое до того места, где показываются описатели, представляющие объекты «файл»; они помечаются как «File».

B данном примере у процесса Csrss имеются открытые описатели объектов «файл», которые представляют открытые экземпляры устройств и получают автоматически генерируемые имена, а также описатели объектов «файл», принадлежащих драйверу службы терминалов. Чтобы просмотреть конкретный объект «файл» в отладчике ядра, сначала определите адрес этого объекта. Следующая команда выводит сведения о выделенном на иллюстрации описателе (0xB8), который принадлежит процессу Csrss.exe с идентификатором 2332 (0x91c):

Поскольку это объект «файл», вы можете получить информацию о нем командой !fileobj:

Поскольку объект «файл» — представление разделяемого ресурса в памяти, а не сам ресурс, он отличается от остальных объектов исполнительной системы. Объект «файл» содержит лишь данные, уникальные для описателя объекта, тогда как собственно файл — совместно используемые данные или текст. Всякий раз, когда поток открывает описатель файла, создается новый объект «файл» с новым набором атрибутов, специфичным для этого описателя. Например, атрибут «текущее смещение в байтах» определяет место в файле, где будут записаны или считаны следующие данные по текущему описателю. У каждого описателя одного и того же файла свое значение атрибута «текущее смещение в байтах». Кроме того, объект «файл» уникален для процесса; исключение составляют случаи, когда процесс дублирует описатель файла для передачи другому процессу (через Windows-функцию DuplicateHandle) или когда дочерний процесс наследует описатель файла от родительского. Только в этих двух случаях процессы располагают отдельными описателями, которые ссылаются на один и тот же объект «файл».

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

Имя открываемого файла включает имя объекта «устройство», который представляет устройство, содержащее файл. Например, \Device\FloppyO\Myfile.dat ссылается на файл Myfile.dat на дискете в дисководе А. Подстрока «\Device\FloppyO» является внутренним именем объекта «устройство», представляющего данный дисковод. При открытии файла Myfile.dat диспетчер ввода-вывода создает объект «файл», сохраняет в нем указатель на объект «устройство» FloppyO и возвращает описатель файла вызывающему потоку. Впоследствии, когда вызывающий поток воспользуется описателем файла, диспетчер ввода-вывода сможет обращаться непосредственно к объекту FloppyO. Учтите, что внутренние имена устройств неприменимы в Window's-приложениях. Для них имена устройств должны находиться в специальном каталоге пространства имен диспетчера объектов — \?? (в Windows 2000) или \Global?? (в Windows XP и Windows Server 2003). B этом каталоге содержатся символьные ссылки на внутренние имена устройств. За создание ссылок в этом каталоге отвечают драйверы устройств. Вы можете просмотреть и даже изменить эти ссылки программным способом, через Windows-функции QueryDosDevice и DefineDosDevice.

ЭКСПЕРИМЕНТ: просмотр сопоставлений Windows-имен устройств внутренним именам устройств

Утилита Winobj (wwwsysinternak.com) позволяет исследовать символьные ссылки, определяющие пространство Windows-имен устройств. Запустите Winobj и выберите каталог \?? в Windows 2000 или \Global?? в Windows XP либо Windows Server 2003.

Обратите внимание на символьные ссылки справа. Попробуйте дважды щелкнуть устройство С: — вы должны увидеть нечто вроде того, что показано ниже.

С: представляет собой символьную ссылку на внутреннее устройство с именем \Device\HarddiskVolumel, или на первый том первого жесткого диска в системе. Элемент COMl, показанный Winobj, — символьная ссылка на \Device\SerialO и т. д. Попробуйте создать собственные ссылки командой subst в командной строке.

Обработка ввода-вывода

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

Типы ввода-вывода

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

Синхронный и асинхронный ввод-вывод

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

Асинхронный ввод-вывод позволяет приложению выдать запрос на ввод-вывод и продолжить выполнение, не дожидаясь передачи данных устройством. Этот тип ввода-вывода увеличивает эффективность работы приложения, позволяя заниматься другими задачами, пока выполняется операция ввода-вывода. Для использования асинхронного ввода-вывода вы должны указать при вызове CreateFile флаг FILE_FLAG_OVERLAPPED. Конечно, инициировав операцию асинхронного ввода-вывода, поток должен соблюдать осторожность и не обращаться к запрошенным данным до их получения от устройства. Следовательно, поток должен синхронизировать свое выполнение с завершением обработки запроса на ввод-вывод, отслеживая описатель синхронизирующего объекта (которым может быть событие, порт завершения ввода-вывода или сам объект «файл»), который по окончании ввода-вывода перейдет в свободное состояние.

Независимо от типа запроса операции ввода-вывода, инициированные драйвером в интересах приложения, выполняются асинхронно, т. е. после выдачи запроса драйвер устройства возвращает управление подсистеме ввода-вывода. A когда она вернет управление приложению, зависит от типа запроса. Схема управления при инициации операции чтения показана на рис. 9–8. Заметьте, что ожидание зависит от состояния флага перекрытия в объекте «файл» и реализуется функцией NtReadFile в режиме ядра.

Вы можете проверить статус незавершенной операции асинхронного ввода-вывода вызовом Windows-функции HasOverlappedIoCompleted. При использовании портов завершения ввода-вывода с той же целью можно вызывать GetQueuedCompletionStatus.

Быстрый ввод-вывод

Быстрый ввод-вывод (fast I/O) — специальный механизм, который позволяет подсистеме ввода-вывода напрямую, не генерируя IRP, обращаться к драйверу файловой системы или диспетчеру кэша (быстрый ввод-вывод описывается в главах 11 и 12). Драйвер регистрирует свои точки входа для быстрого ввода-вывода, записывая их адреса в структуру, на которую ссылается указатель PFASTIODISPATCH его объекта «драйвер».

ЭКСПЕРИМЕНТ: просмотр процедур быстрого ввода-вывода, зарегистрированных драйвером

Список процедур быстрого ввода-вывода, зарегистрированных драйвером в своем объекте «драйвер», выводит команда !drvobj отладчика ядра. Ho такие процедуры обычно имеют смысл только для драйверов файловой системы. Ниже показан список процедур быстрого ввода-вывода для объекта драйвера файловой системы NTFS.

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

Ввод-вывод в проецируемые файлы и кэширование файлов

Ввод-вывод в проецируемые файлы (mapped file I/O) — важная функция подсистемы ввода-вывода, поддерживаемая ею совместно с диспетчером памяти (о проецируемых файлах см. главу 7). Термин «ввод-вывод в проецируемые файлы» относится к возможности интерпретировать файл на диске как часть виртуальной памяти процесса. Программа может обращаться к такому файлу как к большому массиву, не прибегая к буферизации или дисковому вводу-выводу. При доступе программы к памяти диспетчер памяти использует свой механизм подкачки для загрузки нужной страницы из дискового файла. Если программа изменяет какие-то данные в своем виртуальном адресном пространстве, диспетчер памяти записывает эти данные обратно в дисковый файл в ходе обычной операции подкачки страниц.

Ввод-вывод в проецируемые файлы доступен в пользовательском режиме через Windows-функции CreateFileMapping и MapViewOfFile. B самой операционной системе такой ввод-вывод используется при выполнении важных операций — при кэшировании файлов и активизации образов (загрузке и запуске исполняемых программ). Другим потребителем этого типа ввода-вывода является диспетчер кэша. Файловые системы обращаются к диспетчеру кэша для проецирования файлов данных на виртуальную память, что ускоряет работу программ, интенсивно использующих ввод-вывод. По мере использования файла диспетчер памяти подгружает в память страницы, к которым производится обращение. Если большинство систем кэширования выделяет для кэширования фиксированную область памяти, то кэш Windows расширяется или сокращается в зависимости от объема свободной памяти. Такое изменение размера кэша возможно благодаря тому, что диспетчер кэша опирается на соответствующую поддержку со стороны диспетчера памяти (см. главу 7). Используя преимущества подсистемы подкачки страниц диспетчера памяти, диспетчер кэша избегает дублирования работы, уже проделанной диспетчером памяти. (Внутреннее устройство диспетчера кэша рассматривается в главе 11.)

Ввод-вывод по механизму «scatter/gather»

Windows также поддерживает особый вид высокопроизводительного ввода-вывода с использованием механизма «scatter/gather»; он доступен через Windows-функции ReadFileScatter и WriteFileGather. Эти функции позволяют приложению в рамках одной операции считывать или записывать данные из нескольких буферов в виртуальной памяти в непрерывную область дискового файла, а не выдавать отдельный запрос ввода-вывода для каждого буфера. Чтобы задействовать такой ввод-вывод, вы должны открыть файл для некэшируемого асинхронного (перекрывающегося) ввода-вывода и выровнять пользовательские буферы по границам страниц. Более того, если ввод-вывод направлен на устройство массовой памяти, то передаваемые данные нужно выровнять по границам секторов устройства, а их объем должен быть кратен размеру сектора.

Пакеты запроса ввода-вывода

Пакет запроса ввода-вывода (I/O request packet, IRP) хранит информацию, нужную для обработки запроса на ввод-вывод. Когда поток вызывает сервис ввода-вывода, диспетчер ввода-вывода создает IRP для представления операции в процессе ее выполнения подсистемой ввода-вывода. По возможности диспетчер ввода-вывода выделяет память под IRP в одном из двух ассоциативных списков IRP, индивидуальных для каждого процессора и хранящихся в пуле неподкачиваемой памяти. Ассоциативный список малых IRP (small-

IRP look-aside list) хранит IRP с одним блоком стека (об этих блоках — чуть позже), а ассоциативный список больших IRP (large-IRP look-aside list) — IRP с несколькими блоками стека. По умолчанию в IRP второго списка содержится 8 блоков стека, но раз в минуту система варьирует это число на основании того, сколько блоков было запрошено. Если для IRP требуется больше блоков стека, чем имеется в ассоциативном списке больших IRP, диспетчер ввода-вывода выделяет память под IRP из пула неподкачиваемой памяти. После создания и инициализации IRP диспетчер ввода-вывода сохраняет в IRP указатель на объект «файл» вызывающего потока.

ПРИМЕЧАНИЕ DWORD-параметр реестра HKLM\System\CurrentControlSet\Session Manager\I/O System\LargIrpStackLocations (если он определен) указывает, сколько блоков стека содержится в IRP, которые хранятся в ассоциативном списке больших IRP

Ha рис. 9–9 показан пример запроса ввода-вывода, демонстрирующий взаимосвязи между IRP и объектами «файл», «устройство» и «драйвер». Данный пример относится к запросу ввода-вывода, который адресован одноуровневому драйверу, но большинство операций ввода-вывода гораздо сложнее, так как в их выполнении участвует не один, а несколько многоуровневых драйверов. (Этот случай мы рассмотрим позже.)

Блок стека IRP

IRP состоит из двух частей: фиксированного заголовка (часто называемого телом IRP) и одного или нескольких блоков стека. Фиксированная часть содержит такую информацию, как тип и размер запроса, указатель на буфер в случае буферизованного ввода-вывода, данные о состоянии, изменяющиеся по мере обработки запроса, а также сведения о том, является запрос синхронным или асинхронным. Блок стека IRP (IRP stack location) содержит номер функции (состоящий из основного и дополнительного номеров), параметры, специфичные для функции, и указатель на объект «файл» вызывающего потока. Основной номер функции (major function code) идентифицирует принадлежащую драйверу процедуру диспетчеризации, которую диспетчер ввода-вывода вызывает при передаче IRP драйверу. Необязательный дополнительный номер функции (minor function code) иногда используется как модификатор основного номера. B командах управления электропитанием и Plug and Play всегда указывается дополнительный номер функции.

B большинстве драйверов процедуры диспетчеризации определены только для подмножества основных функций, т. е. функций, предназначенных для создания/открытия, записи, чтения, управления вводом-выводом на устройстве, управления электропитанием, операций Plug and Play, System (для WMI-команд) и закрытия. Драйверы файловой системы определяют функции для всех (или почти всех) точек входа. Диспетчер ввода-вывода записывает в точки входа, не заполненные драйверами, указатели на свою функцию IopInvalidDeviceRequest. Эта функция возвращает вызывающему потоку код ошибки, который уведомляет о попытке обращения к функции, не поддерживаемой данным устройством.

ЭКСПЕРИМЕНТ: исследуем процедуры диспетчеризации, принадлежащие драйверу

Вы можете получить список всех функций, определенных драйвером для своих процедур диспетчеризации. Для этого введите команду !drvobj отладчика ядра и после имени (или адреса) объекта «драйвер» укажите значение 7. Следующий вывод показывает, что драйверы поддерживают 28 типов IRR

Каждый IRP, пока он активен, хранится в списке IRP, сопоставленном с потоком, который выдал запрос на ввод-вывод. Это позволяет подсистеме ввода-вывода найти и отменить любые незавершенные IRP, если выдавший их поток завершается.

ЭКСПЕРИМЕНТ: просмотр незавершенных IRP потока

Команда !thread выводит любые IRP, сопоставленные с потоком. Запустите отладчик ядра в работающей системе и найдите процесс диспетчера управления сервисами (Services.exe) в выводе, сгенерированном командой !process\

Теперь создайте дамп потоков для процесса, выполнив команду !process применительно к объекту «процесс». Вы должны увидеть множество потоков, у большинства из которых есть IRP; эти IRP отображаются в блоке IRP List информации о потоке (заметьте, что отладчик выводит лишь первые 17 IRP для потока, у которого имеется более 17 незавершенных запросов ввода-вывода):

У этого IRP основной номер функции — 3, что соответствует IRP_ MJ_READ. Он содержит один блок стека и адресован устройству, принадлежащему драйверу Npfs (Named Pipe File System). (Информацию о Npfs см. в главе 13.)

Управление буфером IRP

Когда приложение или драйвер устройства неявно создает IRP с помощью системного сервиса NtReadFile, NtWriteFile или NtDeviceIoControlFile (этим сервисам соответствуют Windows-функции ReadFile, WriteFile и DeviceIoControt), диспетчер ввода-вывода определяет, должен ли он участвовать в управлении буферами ввода и вывода вызывающего потока. Диспетчер ввода-вывода поддерживает три вида управления буферами.

• Буферизованный ввод-вывод (buffered I/O) Диспетчер ввода-вывода выделяет в пуле неподкачиваемой памяти буфер, равный по размеру буферу вызывающего потока. Создавая IRP при операциях записи, диспетчер ввода-вывода копирует данные из буфера вызывающего потока в выделенный буфер. Завершая обработку IRP при операциях чтения, диспетчер ввода-вывода копирует данные из выделенного буфера в пользовательский буфер и освобождает выделенный буфер.

• Прямой ввод-вывод (direct I/O) Создавая IRP, диспетчер ввода-вывода блокирует пользовательский буфер в памяти (делает его неподкачиваемым). Закончив работу с IRP, диспетчер ввода-вывода разблокирует буфер. Диспетчер хранит описание этой памяти в форме MDL (memory descriptor list). MDL указывает объем физической памяти, занятой буфером (подробнее о MDL см. Windows DDK). Устройствам, использующим DMA (прямой доступ к памяти), требуется лишь физическое описание буфера, поэтому таким устройствам достаточно MDL. (Устройства, поддерживающие DMA, передают данные в память компьютера напрямую, не используя процессор.) Ho, если драйверу нужен доступ к содержимому буфера, он может спроецировать его на системное адресное пространство.

• Ввод-вывод без управления (neither I/O) Диспетчер ввода-вывода не участвует в управлении буферами. Ответственность за управление ими возлагается на драйвер устройства.

При любом типе управления буферами диспетчер ввода-вывода помещает в IRP ссылки на буферы ввода и вывода. Тип управления буферами, реализуемого диспетчером ввода-вывода, зависит от типа управления, запрошенного драйвером для операций конкретного типа. Драйвер регистрирует нужный ему тип управления буферами для операций чтения и записи в объекте «устройство», который представляет устройство. Операции управления вводом-выводом на устройстве (выполняемые NtDeviceIoControlFile) задаются определенными в драйвере управляющими кодами ввода-вывода. Управляющий код включает тип управления буферами со стороны диспетчера ввода-вывода при обработке IRP с данным кодом.

Когда вызывающие потоки передают запросы размером менее одной страницы (4 Кб на х86-процессорах), драйверы, как правило, используют буферизованный ввод-вывод, а для запросов большего размера — прямой. Буфер примерно равен размеру страницы, и операция копирования с применением буферизованного ввода-вывода приводит практически к тем же издержкам, что и прямой ввод-вывод, требующий блокирования памяти. Драйверы файловой системы обычно используют третий тип управления, так как при копировании данных из кэша файловой системы в буфер вызывающего потока это позволяет избавиться от издержек, связанных с управлением буферами. Ho большинство драйверов не использует этот вид управления из-за того, что указатель на буфер вызывающего потока действителен лишь на то время, пока выполняется этот поток. Если драйверу нужно передать данные с устройства (или на устройство) при выполнении DPC-процедуры или ISR, он должен позаботиться о доступности данных вызывающего потока из контекста любого процесса, а значит, у буфера должен быть системный виртуальный адрес.

Драйверы, использующие ввод-вывод без управления для доступа к буферам, которые могут быть расположены в пользовательском пространстве, должны проверять, что адреса буфера действительны и не ссылаются на память режима ядра. Если они этого не делают, появляется вероятность краха системы или уязвимости в системе защиты, так как приложения получают доступ к памяти режима ядра или возможность внедрения своего кода в ядро. Функции ProbeForRead и ProbeForWrite, которые ядро предоставляет драйверам, проверяют, полностью ли умещается буфер в пользовательской части адресного пространства. Чтобы избежать краха из-за ссылки на недопустимый адрес, драйверы могут обращаться к буферам пользовательского режима из кода обработки исключений (блоков try/except), который перехватывает любые попытки доступа по неправильным адресам и транслирует их в коды ошибок для передачи приложению.

Запрос ввода-вывода к одноуровневому драйверу

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

1. Запрос на ввод-вывод передается через DLL подсистемы.

2. DLL подсистемы вызывает сервис NtWriteFile диспетчера ввода-вывода.

3. Диспетчер ввода-вывода создает IRP, описывающий запрос, и посылает его драйверу (в данном случае — драйверу устройства), вызывая свою функцию IoCallDriver.

4. Драйвер передает данные из IRP на устройство и инициирует операцию ввода-вывода.

5. Драйвер уведомляет о завершении ввода-вывода, генерируя прерывание.

6. Когда устройство завершает операцию и вызывает прерывание, драйвер устройства обслуживает прерывание.

7. Драйвер вызывает функцию IoCompleteRequest диспетчера ввода-вывода, чтобы уведомить его о завершении обработки IRP, и диспетчер ввода-вывода завершает данный запрос на ввод-вывод.

Эти семь этапов показаны на рис. 9-10.

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

Обслуживание прерывания

Завершая передачу данных, устройство генерирует прерывание, после чего в дело вступают ядро Windows, диспетчер ввода-вывода и драйвер устройства. Ha рис. 9-11 показана первая фаза этого процесса. (Механизм диспетчеризации прерываний, включая DPC, описывается в главе 3. Мы кратко повторяем этот материал, потому что DPC играют ключевую роль в обработке ввода-вывода.)

Когда устройство генерирует прерывание, процессор передает управление обработчику ловушки ядра, который находит ISR для этого устройства по таблице диспетчеризации прерываний. ISR в Windows обычно обрабатывают прерывания от устройств в два этапа. При первом вызове ISR, как правило, остается на уровне Device IRQL ровно столько времени, сколько нужно для того, чтобы сохранить состояние устройства и запретить дальнейшие прерывания от него. После этого ISR помещает DPC в очередь и, закрыв прерывание, завершается. Впоследствии, при вызове DPC-процедуры драйвер устройства заканчивает обработку прерывания, а затем вызывает диспетчер ввода-вывода для завершения ввода-вывода и удаления IRR Этот драйвер также может начать выполнение следующего запроса ввода-вывода, ждущего в очереди устройства.

Преимущество выполнения большей части обработки прерываний от устройств через DPC в том, что это разрешает любые блокируемые прерывания с приоритетами от «Device IRQL» до «DPC/dispatch» — пока не началась обработка DPC, имеющего более низкий приоритет. A за счет этого удается более оперативно (чем это могло бы быть в ином случае) обслуживать прерывания среднего приоритета. Вторая фаза ввода-вывода (обработка DPC) показана на рис. 9-12.

Завершение обработки запроса на ввод-вывод

После того как DPC-процедура драйвера выполнена, до завершения запроса на ввод-вывод остается проделать кое-какую оставшуюся работу. Третья стадия обработки ввода-вывода называется завершением ввода-вывода (I/O completion) и начинается с вызова драйвером функции IoСотрleteRequest для уведомления диспетчера ввода-вывода о том, что обработка запроса, указанного в IRP (и принадлежащих ему блоках стека), закончена. Действия, выполняемые на этом этапе, различны для разных операций ввода-вывода. Например, все сервисы ввода-вывода записывают результат операции в блок статуса ввода-вывода (I/O status block) — структуру данных, предоставляемую вызывающим потоком. Некоторые сервисы, выполняющие буферизованный ввод-вывод, требуют возврата данных вызывающему потоку через подсистему ввода-вывода.

B любом случае подсистема ввода-вывода должна копировать отдельные данные из системной памяти в виртуальное адресное пространство процесса, которому принадлежит вызывающий поток. Если IRP выполняется синхронно, это адресное пространство является текущим и доступно напрямую, но если IRP обрабатывается асинхронно, диспетчер ввода-вывода должен отложить завершение IRP до тех пор, пока у него не появится возможность обращаться к нужному адресному пространству. Чтобы получить доступ к виртуальному адресному пространству процесса, которому принадлежит вызывающий поток, диспетчер ввода-вывода должен передавать данные «в контексте вызывающего потока», т. е. при выполнении этого потока (иначе говоря, процесс этого потока должен быть текущим, а его адресное пространство — активным на процессоре). Эту задачу диспетчер ввода-вывода решает, ставя в очередь данному потоку APC режима ядра (рис. 9-13).

Как уже говорилось в главе 3, APC выполняется только в контексте определенного потока, a DPC — в контексте любого потока. Это означает, что DPC не затрагивает адресное пространство процесса пользовательского режима. Вспомните также, что приоритет программного прерывания у DPC выше, чем у APC

B следующий раз, когда поток начинает выполняться при низком IRQL, ему доставляется отложенный APC Ядро передает управление АРС-процедуpe диспетчера ввода-вывода, которая копирует данные (если они есть) и код возврата в адресное пространство процесса вызывающего потока, освобождает IRP, представляющий данную операцию ввода-вывода, и переводит описатель файла (и любое событие или порт завершения ввода-вывода, если таковой объект предоставлен вызывающим потоком) в свободное состояние. Теперь ввод-вывод считается завершенным. Вызывающий поток или любые другие потоки, ждущие на описателе файла (или иного объекта), выходят из состояния ожидания и переходят в состояние готовности к выполнению. Вторая фаза завершения ввода-вывода показана на рис. 9-14.

И последнее замечание о завершении ввода-вывода. Функции асинхронного ввода-вывода ReadFileEx и WriteFileEx принимают в качестве параметра APC пользовательского режима. Если поток передаст этот параметр, то на последнем этапе диспетчер ввода-вывода направит соответствующий APC в очередь данного потока. Эта функциональность позволяет вызывающему потоку указывать процедуру, которую нужно вызывать после завершения или отмены запроса ввода-вывода. Такие APC выполняются в контексте вызывающего потока и доставляются, только если поток переходит в состояние «тревожного» ожидания (как, например, при вызове Windows-функции SleepEx, WaitForSingleObjectEx или WaitForMultipleObjectsEx).

Синхронизация

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

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

• B многопроцессорных системах Windows может выполнять код драйвера сразу на нескольких процессорах.

Без синхронизации данные могут быть повреждены. Например, код драйвера устройства выполняется при IRQL уровня «passive». Какая-то программа инициирует операцию ввода-вывода, в результате чего возникает аппаратное прерывание. Оно прерывает выполнение кода драйвера и активизирует его ISR. Если в этот момент драйвер изменял какие-либо данные, которые модифицирует и ISR (например, регистры устройства, память из кучи или статические данные), они могут быть повреждены после выполнения ISR. Эту проблему демонстрирует рис. 9-15.

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

Ядро Windows предоставляет специальную синхронизирующую процедуру KeSynchronizeExecution, которую драйверы устройств должны вызывать при доступе к данным, разделяемым с ISR. Эта процедура не допускает выполнения ISR, пока драйвер обращается к общим данным. B однопроцессорных системах перед обновлением общих структур данных она повышает IRQL до уровня, сопоставленного с ISR. Ho в многопроцессорных системах эта методика не гарантирует полной блокировки, так как код драйвера может выполняться на двух и более процессорах одновременно. Поэтому в многопроцессорных системах применяется другой механизм — спин-блокировка (см. раздел «Синхронизация ядра» главы 3). Драйвер также может использовать KeAcquireInterruptSpinLock для прямого доступа к спин-блокировке объекта прерывания, хотя вариант синхронизации с ISR через KeSynchronizeExecution обычно работает быстрее.

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

Запрос ввода-вывода к многоуровневому драйверу

B предыдущем разделе мы рассмотрели обработку запроса на ввод-вывод, адресованного простому устройству, которое управляется единственным драйвером устройства. Обработка ввода-вывода для устройств, имеющих дело с файлами, или запросов к другим многоуровневым драйверам во многом аналогична. Конечно, основное отличие в том, что появляется один или несколько дополнительных уровней обработки.

Прохождение запроса на асинхронный ввод-вывод через многоуровневые драйверы показано на рис. 9-l6. Данный пример относится к диску, управляемому файловой системой.

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

ЭКСПЕРИМЕНТ: просмотр стека устройства

Команда !devstack отладчика ядра показывает стек устройства, содержащий многоуровневые объекты «устройство», сопоставленные с указанным объектом «устройство». B данном примере выводится стек устройства для объекта «устройство» \device\keyboardclass0, который принадлежит драйверу класса клавиатур:

Строка для KeyboardClass0 выделяется префиксом «›». Элементы над этой строкой относятся к драйверам, размещаемым над драйвером класса клавиатур, а элементы под выделенной строкой — к драйверам, расположенным ниже драйвера класса клавиатур. B целом, IRP передаются по стеку сверху вниз.

Файловая система скорее всего будет повторно использовать IRP, если полученный запрос можно преобразовать в единый запрос к устройству. Например, если приложение выдаст запрос на чтение первых 512 байтов из файла на дискете, файловая система FAT просто вызовет драйвер диска, попросив его считать один сектор с того места на дискете, где начинается нужный файл.

Для поддержки использования несколькими драйверами IRP содержит набор блоков стека (не путать со стеком потока). Эти блоки данных — по одному на каждый вызываемый драйвер — хранят информацию, необходимую каждому драйверу для обработки своей части запроса (например, номер функции, параметры, сведения о контексте драйвера). Как показано на рис. 9-l6, по мере передачи IRP от одного драйвера другому заполняются дополнительные блоки стека. IRP можно считать аналогом стека в отношении добавления и удаления данных. Ho IRP не сопоставляется ни с каким процессом, и его размер фиксирован. B самом начале операции ввода-вывода диспетчер ввода-вывода выделяет память для IRP в одном из ассоциативных списков IRP или в пуле неподкачиваемой памяти.

ЭКСПЕРИМЕНТ: исследуем IRP

B этом эксперименте вы найдете незавершенные IRP в системе и определите тип IRP, устройство, которому он адресован, драйвер, управляющий этим устройством, поток, выдавший IRP, и процесс, к которому относится данный поток.

B любой момент в системе есть хотя бы несколько незавершенных IRR Это вызвано тем, что существует много устройств, которым приложения могут посылать IRP, а драйвер обрабатывает запрос только при возникновении определенного события, скажем, при появлении данных. Один из примеров — чтение с сетевого устройства. Увидеть незавершенные IRP в системе позволяет команда !irpfind отладчика ядра:

Строка, выделенная в выводе, описывает IRP, адресованный драйверу Kbdclass, так что этот IRP скорее всего был выдан потоком необработанного ввода для подсистемы Windows, принимающим ввод с клавиатуры. Изучение IRP с помощью команды !irp показывает следующее:

Активный блок стека (помечаемый префиксом «›», находится в самом низу. Основной номер функции равен 3, что соответствует IRP_MJ_READ.

Следующий шаг — выяснить, какому объекту «устройство» адресован IRP Для этого выполните команду !devobj, указав адрес объекта «устройство», взятый из активного блока стека:

Устройство, которому адресован данный IRP, — KeyboardClassl. Наличие объекта «устройство», принадлежащего драйверу Termdd, сообщает, что этот объект представляет ввод от клиента службы терминалов, а не с физической клавиатуры. (Листинг был получен в системе с Windows XP.)

Детальные сведения о потоке и процессе, выдавшем этот IRP, можно просмотреть командами !thread и /process:

Найдя этот поток в Process Explorer (www.sysinternals.com) на вкладке Threads окна свойств для Csrss.exe, вы убедитесь, что, судя по именам функций в его стеке, он действительно является потоком необработанного ввода (raw input thread) для подсистемы Windows.

После того как драйвер диска завершает передачу данных, диск генерирует прерывание, и ввод-вывод завершается (рис. 9-17).

Рис. 9-17. Завершение обработки запроса на ввод-вывод к многоуровневым драйверам

B качестве альтернативы повторному использованию единственного IRP файловая система может создать группу сопоставленных IRP (associated IRPs), которые будут обрабатываться параллельно. Например, если данные, которые нужно считать из файла, разбросаны по всему диску, драйвер файловой системы может создать несколько IRP, каждый из которых инициирует чтение данных из отдельного сектора. Этот случай иллюстрирует рис. 9-18.

Драйвер файловой системы передает сопоставленные IRP драйверу устройства, который ставит их в очередь устройства. Они обрабатываются по одному, а файловая система отслеживает возвращаемые данные. Когда выполнение всех сопоставленных IRP заканчивается, подсистема ввода-вывода завершает обработку исходного IRP и возвращает управление вызывающему потоку (рис. 9-19).

ПРИМЕЧАНИЕ Все драйверы, управляющие дисковыми файловыми системами в Windows, являются частью как минимум трехуровневого стека драйверов: драйвер файловой системы находится на верхнем уровне, диспетчер томов — на среднем, а драйвер диска — на нижнем. Кроме того, между этими драйверами может размещаться любое число драйверов фильтров. Для ясности в предыдущем примере были показаны лишь драйверы файловой системы и диска. Подробнее об управлении внешней памятью см. главу 10.

Порты завершения ввода-вывода

Создание высокопроизводительного серверного приложения требует реализации эффективной модели многопоточности. Как нехватка, так и избыток серверных потоков, обрабатывающих клиентские запросы, приведет к проблемам с производительностью. Например, если сервер создает единственный поток для обработки всех запросов, клиенты будут «голодать», так как сервер будет обрабатывать по одному запросу единовременно. Конечно, единственный поток мог бы обрабатывать сразу несколько запросов, переключаясь с одной операции ввода-вывода на другую. Однако такая архитектура крайне сложна и не позволяет использовать преимущества многопроцессорных систем. Другая крайность — создание сервером огромного пула потоков, когда для обработки чуть ли не каждого клиентского запроса выделяется свой поток. Этот сценарий обычно ведет к перегрузке процессоров потоками: множество потоков пробуждается, выполняет обработку данных, блокируется в ожидании ввода-вывода, а после обработки запроса снова блокируется в ожидании нового запроса. Одно только наличие слишком большого количества потоков заставило бы планировщик чрезмерно часто переключать контекст, и в итоге он отобрал бы на себя немалую часть процессорного времени.

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

Объект loCompletion

Приложения используют объект loCompletion исполнительной системы, который экспортируется в Windows как порт завершения (completion port) — фокальная точка завершения ввода-вывода, сопоставляемая с множеством описателей файлов. Если какой-нибудь файл сопоставлен с портом завершения, то по окончании любой операции асинхронного ввода-вывода, связанной с этим файлом, в очередь порта завершения ставится пакет завершения (completion packet). Ожидание завершения любой из операций ввода-вывода в нескольких файлах может быть реализовано простым ожиданием соответствующего пакета завершения, который должен появиться в очереди порта завершения. Windows API поддерживает аналогичную функциональность через WaitForMultipleObjects, но порты завершения дают одно большое преимущество: число потоков, активно обслуживающих клиентские запросы, контролируется самой системой.

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

Использование портов завершения

Высокоуровневая схема работы порта завершения представлена на рис. 9-20. Порт завершения создается вызовом Windows-функции CreateIoCompletionPort. Потоки, блокированные на порте завершения, считаются сопоставленными с ним и пробуждаются по принципу LIFO («последним пришел — первым вышел»), т. е. следующий пакет достается потоку, заблокированному последним. Стеки потоков, блокируемых в течение длительного времени, могут быть выгружены в страничный файл. B итоге, если с портом сопоставлено больше потоков, чем нужно для обработки текущих заданий, система автоматически минимизирует объем памяти, занимаемой слишком долго блокируемыми потоками.

Серверное приложение обычно получает клиентские запросы через конечные точки, представляемые как описатели файлов. Пример — сокеты Windows Sockets 2 (Winsock2) или именованные каналы. Создавая конечные точки своих коммуникационных связей, сервер сопоставляет их с портом завершения, и серверные потоки ждут входящие запросы, вызывая для этого порта функцию GetQueuedCompletionStatus. Получив пакет из порта завершения, поток начинает обработку запроса и становится активным. B процессе обработки данных поток может часто блокироваться, например из-за необходимости считать данные из файла или записать их в него, а также из-за синхронизации с другими потоками. Windows обнаруживает такие действия и выясняет, что одним активным потоком на порте завершения стало меньше. Поэтому, как только поток блокируется и становится неактивным, операционная система пробуждает другой ждущий на порте завершения поток (если в очереди есть пакет).

Microsoft рекомендует устанавливать максимальное число активных потоков на порте завершения примерно равным числу процессоров в системе. Имейте в виду, что это значение может быть превышено. Допустим, вы задали, что максимальное значение должно быть равно 1. При поступлении клиентского запроса выделенный для его обработки поток становится активным. Поступает второй запрос, но второй поток не может продолжить его обработку, так как лимит уже достигнут. Затем первый поток блокируется в ожидании файлового ввода-вывода и становится неактивным. Тогда освобождается второй поток и, пока он активен, завершается файловый ввод-вывод для первого потока, в результате чего первый поток вновь активизируется. C этого момента и до блокировки одного из потоков число активных потоков превышает установленный лимит на 1.

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

Как работает порт завершения ввода-вывода

Windows-приложения создают порты завершения вызовом Windows-функции CreateIoCompletionPort с указанием NULL вместо описателя порта завершения. Это приводит к выполнению системного сервиса NtCreateIoComple-tion. Объект IoCompletion исполнительной системы, построенный на основе синхронизующего объекта ядра, называется очередью. Таким образом, системный сервис создает объект «порт завершения» и инициализирует объект «очередь» в памяти, выделенной для порта. (Указатель на порт ссылается и на объект «очередь», так как последний находится в начальной области памяти порта.) Максимальное число сопоставленных с портом потоков, которые могут быть активны, указывается в объекте «очередь» при его инициализации; это значение, которое было передано в CreateIoCompletionPort. Для инициализации объекта «очередь» порта завершения NtCreateIoCompletion вызывает функцию KeInitializeQueue.

Когда приложение обращается к CreateIoCompletionPort для связывания описателя файла с портом, вызывается системный сервис NtSetInformationFile, которому передается описатель этого файла. При этом класс информации для NtSetInformationFile устанавливается как FileCompletionInformation, и, кроме того, эта функция принимает описатель порта завершения и параметр CompletionKey, ранее переданный в CreateIoCompletionPort. Функция NtSetInformationFile производит разыменование описателя файла для получения объекта «файл» и создает структуру данных контекста завершения.

Указатель на эту структуру NtSetInformationFile помещает в поле Com-pletionContext объекта «файл». По завершении асинхронной операции ввода-вывода для объекта «файл» диспетчер ввода-вывода проверяет, отличается ли поле CompletionContext от NULL. Если да, он создает пакет завершения и ставит его в очередь порта завершения вызовом KeInsertQueue; при этом в качестве очереди, в которую помещается пакет, указывается порт. (Здесь объект «порт завершения» — синоним объекта «очередь».)

Когда серверный поток вызывает GetQueuedCompletionStatus, выполняется системный сервис NtRemoveIoCompletion. После проверки параметров и преобразования описателя порта завершения в указатель на порт NtRemoveIoCompletion вызывает KeRemoveQueue.

Как видите, KeRemoveQueue и KeInsertQueue — это базовые функции, обеспечивающие работу порта завершения. Они определяют, следует ли активизировать поток, ждущий пакет завершения ввода-вывода. Объект «очередь» поддерживает внутренний счетчик активных потоков и хранит такое значение, как максимальное число активных потоков. Если при вызове потоком KeRemoveQueue текущее число активных потоков равно максимуму или превышает его, данный поток будет включен (в порядке LIFO) в список потоков, ждущих пакет завершения. Список потоков отделен от объекта «очередь». B блоке управления потоком имеется поле для указателя на очередь, сопоставленную с объектом «очередь»; если это поле пустое, поток не связан с очередью.

Windows отслеживает потоки, ставшие неактивными из-за ожидания на каких-либо объектах, отличных от порта завершения, по указателю на очередь, присутствующему в блоке управления потоком. Процедуры планировщика, в результате выполнения которых поток может быть блокирован (KeWaitForSingleObject, KeDelayExecutionThread и т. д.), проверяют этот указатель. Если он не равен NULL, они вызывают функцию KiActivateWaiterQueue, которая уменьшает счетчик числа активных потоков, сопоставленных с очередью. Если конечное число меньше максимального и в очереди есть хотя бы один пакет завершения, первый поток из списка потоков очереди пробуждается и получает самый старый пакет. И напротив, всякий раз, когда после блокировки пробуждается поток, связанный с очередью, планировщик выполняет функцию KiUnwaitTbread, увеличивающую счетчик числа активных потоков очереди.

Наконец, в результате вызова Windows-функции PostQueuedCompletionStatus выполняется системный сервис NtSetIoCompletion, который просто вставляет с помощью KeInsertQueue специальный пакет в очередь порта завершения.

Порт завершения в действии показан на рис. 9-21. Хотя к обработке пакетов завершения готовы два потока, максимум, равный 1, допускает активизацию только одного потока, связанного с портом завершения. Таким образом, на этом порте завершения блокируется два потока.

Driver Verifier

Утилита Driver Verifier (о которой мы уже рассказывали в главе 7) предоставляет несколько параметров для проверки правильности операций, связанных с вводом-выводом. Ha рис. 9-22 в окне Driver Verifier Manager (Диспетчер проверки драйверов) в Windows Server 2003 эти параметры помечены флажками.

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

Рис. 9-22. Параметры Driver Verifier, относящиеся к операциям ввода-вывода

Параметры проверки ввода-вывода перечислены ниже.

• I/O Verification (Проверка ввода-вывода) Если этот параметр выбран, диспетчер ввода-вывода выделяет память под IRP-пакеты для проверяемых драйверов из специального пула и отслеживает его использование. Кроме того, Verifier вызывает крах системы по окончании обработки IRP с неправильным состоянием и при передаче неверного объекта «устройство» диспетчеру ввода-вывода. (B Windows 2000 этот параметр назывался I/O Verification Level 1).

• I/O Verification Level 2 (Проверка ввода-вывода уровня 2) Этот параметр существует только в Windows 2000; он просто ужесточает проверку операций обработки IRP и использования стека.

• Enhanced I/O Verification (Расширенная проверка ввода-вывода) Этот параметр впервые появился в Windows XP и включает мониторинг всех IRP для контроля того, что драйверы корректно помечают их при асинхронной обработке, что они правильно управляют блоками стека устройства и что они удаляют каждый объект «устройство» только раз. B дополнение Verifier случайным образом посылает драйверам ложные IRP, связанные с управлением электропитанием и WMI, изменяет порядок перечисления устройств и изменяет состояние IRP, связанных с PnP и электропитанием, по окончании их обработки; последнее позволяет выявить драйверы, возвращающие неверное состояние из своих процедур диспетчеризации.

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

• Disk Integrity Verification (Проверка целостности диска) После включения этого параметра, доступного только в Windows Server 2003, Verifier ведет мониторинг операций чтения и записи на дисках и проверяет контрольные суммы соответствующих данных. По окончании операций чтения с диска Verifier проверяет ранее сохраненные контрольные суммы и вызывает крах системы, если новая и старая контрольные суммы не совпадают, так как это свидетельствует о повреждении диска на аппаратном уровне.

• SCSI Verification (Проверка SCSI) Этот параметр появился в Windows XP и не виден в диалоговом окне параметров Driver Verifier. Однако он включается, когда вы выбираете для проверки минипорт-драйвер SCSI и отмечаете хотя бы один из других параметров. Тогда Verifier следит, как минипорт-драйвер SCSI использует функции, предоставляемые драйвером библиотеки SCSI-минипорта — storport.sys или scsiport.sys. При этом проверяется, что драйвер не обрабатывает запрос более одного раза, что он не передает недопустимые аргументы и что на выполнение операций не уходит больше определенного времени. (Подробнее о минипорт-драйверах SCSI см. в главе 10.)

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

Диспетчер Plug and Play (PnP)

Диспетчер PnP — основной компонент, от которого зависит способность Windows к распознаванию изменений в аппаратной конфигурации. Благодаря этому от пользователя не требуется знания тонкостей настройки устройств и системы при их установке и удалении. Так, диспетчер PnP позволяет портативному компьютеру с Windows при подключении к стыковочной станции автоматически обнаруживать дополнительные устройства стыковочной станции и делать их доступными пользователю.

Поддержка Plug and Play требует взаимодействия на уровнях оборудования, драйверов устройств и операционной системы. Эта поддержка в Windows базируется на промышленных стандартах перечисления и идентификации подключенных к шинам устройств. Например, стандарт USB определяет способ самоидентификации устройств, подключенных к шине USB. Ha этой основе в Windows реализуются следующие возможности Plug and Play.

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

• Диспетчер PnP выделяет аппаратные ресурсы, собирая информацию о требованиях устройств к аппаратным ресурсам (прерывания, диапазоны адресов ввода-вывода, регистры ввода-вывода или ресурсы, специфичные для шин). B ходе арбитража ресурсов (resource arbitration) диспетчер PnP распределяет ресурсы между устройствами с учетом их требований. Поскольку устройства могут быть добавлены в систему после распределения ресурсов на этапе загрузки, диспетчер PnP должен уметь перераспределять ресурсы.

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

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

Уровень поддержки Plug and Play

Windows нацелена на полную поддержку Plug and Play, но конкретный уровень поддержки зависит от устройств, подключенных к системе, и установленных в ней драйверов. Уровень поддержки Plug and Play может быть снижен, если хотя бы один драйвер или устройство не отвечает стандарту Plug and Play. Более того, драйвер, не поддерживающий Plug and Play может лишить систему возможности использовать другие устройства. B таблице 9–2 показано, к каким результатам приводят различные сочетания устройств и драйверов с поддержкой Plug and Play и без нее.

PnP-несовместимое устройство, например унаследованная звуковая плата с ISA-шиной, не поддерживает автоматическое определение. Из-за этого таким устройствам запрещены некоторые операции вроде «горячего» подключения или перехода в один из режимов сна. Если для такого устройства вручную установить РпР-совместимый драйвер, он сможет по крайней мере использовать ресурсы, которые диспетчер PnP будет выделять этому устройству.

Унаследованные драйверы, например драйверы, разработанные для Windows NT 4, не совместимы с Plug and Play. Хотя они работают в Windows, диспетчер PnP не сможет динамически перераспределять ресурсы, назначенные таким устройствам. Допустим, унаследованное устройство использует для ввода-вывода диапазон памяти A или В. При загрузке системы диспетчер PnP выделяет этому устройству диапазон А. Если впоследствии в систему будет добавлено устройство, способное использовать только диапазон А, диспетчер PnP не сможет указать драйверу первого устройства перенастроить его на диапазон В. Из-за этого второе устройство не получит нужные ресурсы и будет недоступно. Унаследованные драйверы также мешают переходу системы в один из режимов сна (см. раздел «Диспетчер электропитания» далее в этой главе).

Поддержка Plug and Play со стороны драйвера

Для поддержки Plug and Play в драйвере должна быть реализована процедура диспетчеризации Plug and Play, а также процедура добавления устройства. Однако драйверы шин должны поддерживать типы запросов Plug and Play, отличные от тех, которые поддерживаются функциональными драйверами и драйверами фильтров. Так, при перечислении устройств в процессе загрузки диспетчер PnP запрашивает у драйверов шин описание устройств, найденных ими на своих шинах. B это описание входят данные, уникально идентифицирующие каждое устройство, а также требования устройств к аппаратным ресурсам. Диспетчер PnP принимает эту информацию и загружает функциональные драйверы или драйверы фильтров, установленные для обнаруженных устройств. Затем он вызывает процедуру добавления устройства каждого драйвера, установленного для каждого устройства.

Выполняя процедуру добавления устройства, функциональные драйверы и драйверы фильтров готовятся начать управление своими устройствами, но на самом деле пока еще не взаимодействуют с ними. Они ждут команду startdevice, которую диспетчер PnP должен передать их процедурам диспетчеризации Plug and Play. До передачи этой команды диспетчер PnP выполняет арбитраж ресурсов, чтобы решить, какие ресурсы выделить тому или иному устройству. B команде start-device указываются назначенные ресурсы, определенные диспетчером PnP при арбитраже ресурсов. Получив команду start-device, драйвер может настроить свое устройство на использование указанных ресурсов. Если программа пытается открыть устройство, которое не готово к началу работы, она получает код ошибки, указывающий на отсутствие этого устройства.

После запуска устройства диспетчер PnP может посылать драйверу дополнительные PnP-команды, в том числе относящиеся к удалению устройства из системы или перераспределению ресурсов. Например, когда пользователь запускает утилиту, показанную на рис. 9-23, — для ее запуска надо щелкнуть правой кнопкой мыши значок платы PC Card на панели задач и выбрать команду Unplug Or Eject Hardware (Отключение или извлечение аппаратного устройства), — и командует Windows извлечь PCMCIA-плату, диспетчер PnP посылает уведомление query-remove каждому приложению, зарегистрированному на получение PnP-уведомлений об этом устройстве. Как правило, приложения регистрируются на получение уведомлений через свои описатели устройства, которые они закрывают, получая уведомление query-remove. Если ни одно приложение не налагает вето на запрос query-remove, диспетчер PnP посылает команду query-remove драйверу, управляющему извлекаемым устройством. Ha этом этапе драйвер решает, что ему делать дальше: запретить удаление устройства или завершить все операции ввода-вывода на этом устройстве и прекратить дальнейший прием запросов на ввод-вывод, направляемых устройству. Если драйвер отвечает согласием на запрос об удалении и открытых описателей устройства больше нет, диспетчер PnP посылает драйверу команду remove, требующую от него прекратить обращение к устройству и освободить все ресурсы, выделенные им для данного устройства.

Рис. 9-23. Утилита для отключения или извлечения платы PC Card

Когда диспетчеру PnP нужно перераспределить ресурсы для устройства, он сначала запрашивает драйвер, может ли тот временно приостановить операции на устройстве, и с этой целью посылает команду query-stop. Драйвер отвечает на этот запрос согласием, если нет риска потери или повреждения данных; в ином случае он отклоняет такой запрос. Как и в случае команды query-remove, драйвер, согласившись с запросом, заканчивает незавершенные операции ввода-вывода и больше не передает этому устройству запросы на ввод-вывод. (Новые запросы на ввод-вывод драйвер обычно ставит в очередь.) Далее диспетчер PnP посылает драйверу команду stop. Ha этом этапе диспетчер PnP может указать драйверу выделить устройству другие ресурсы, а потом послать команду start-device.

Команды Plug and Play вызывают переход устройства в строго определенные состояния, которые в упрощенной форме представлены на рис. 9-24. (Некоторые состояния и команды Plug and Play на этой иллюстрации опущены. Кроме того, этот вариант относится к диаграмме состояний, реализуемой функциональными драйверами. Диаграмма состояний, реализуемых драйверами шин, гораздо сложнее.) Кстати, на рис. 9-24 показано одно из состояний, которое мы еще не обсудили, — устройство переходит в него после команды surprise-remove диспетчера PnP. Эта команда посылается при неожиданном удалении устройства из системы, например из-за его отказа или из-за извлечения PCMCIA-платы без применения соответствующей утилиты. Команда surprise-remove заставляет драйвер немедленно прекратить всякое взаимодействие с устройством, так как оно больше не подключено к системе, и отменить любые незавершенные запросы ввода-вывода.

Загрузка, инициализация и установка драйвера

Драйвер может загружаться в Windows явно и на основе перечисления. Явную загрузку определяет ветвь реестра HKLM\SYSTEM\CurrentControlSet\Services, и на эту тему см. раздел «Сервисные приложения» главы 4. Загрузка на основе перечисления происходит при динамической загрузке диспетчером PnP драйверов для устройств, о наличии которых сообщает драйвер шины.

Параметр Start

B главе 4 мы объяснили, что у каждого драйвера и Windows-сервиса есть свой раздел в ветви реестра Services текущего набора параметров управления. B этот раздел входят параметры, указывающие тип образа (например, Windows-сервис, драйвер или файловая система), путь к файлу образа драйвера или сервиса и параметры, контролирующие порядок загрузки драйвера или сервиса. Между загрузкой Windows-сервисов и явной загрузкой драйверов есть два главных различия:

• только для драйверов устройств в параметре Start могут быть указаны значения 0 (запуск при загрузке системы) и 1 (запуск системой);

• драйверы устройств могут использовать параметры Group и Tag для контроля порядка своей загрузки при запуске системы, но в отличие от сервисов не могут определять параметры DependOnGroup или DependOnService. B главе 5 мы рассмотрели этапы процесса загрузки и объяснили, что параметр Start драйвера, равный 0, означает, что этот драйвер загружается загрузчиком операционной системы. A если Start равен 1, драйвер загружается диспетчером ввода-вывода после инициализации компонентов исполнительной системы. Диспетчер ввода-вывода вызывает инициализирующие процедуры драйверов в том порядке, в каком драйверы загружались при запуске системы. Как и Windows-сервисы, драйверы используют параметр Group в своем разделе реестра, чтобы указать группу, к которой они принадлежат; порядок загрузки групп определяется параметром HKLM\SYSTEM\ CurrentControlSet\Control\ServiceGroupOrder\List.

Драйвер может еще больше детализировать порядок своей загрузки с помощью параметра Tag, который указывает конкретную позицию драйвера в группе. Диспетчер ввода-вывода сортирует драйверы в группе по значениям параметров Tag, определенных в разделах реестра, соответствующих этим драйверам. Драйверы, не имеющие параметра Tag, перемещаются в конец списка драйверов группы. Вы могли предположить, что диспетчер ввода-вывода сначала инициализирует драйверы с меньшими значениями Tag, потом — с большими, но это не так. Приоритет значений параметров Tag в рамках группы определяется в HKLM\SYSTEM\CurrentControlSet\Control\GroupOrderList; этот раздел реестра дает Microsoft и разработчикам драйверов свободу в определении собственной системы целых чисел.

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

• Драйверы, не поддерживающие Plug and Play, настраивают Start так, чтобы система загружала их на определенном этапе своего запуска.

• Драйверы, которые должны загружаться системным загрузчиком при запуске операционной системы, указывают в Start значение 0 (запуск при загрузке системы). Пример — драйверы системных шин и драйвер файловой системы, используемый при загрузке системы.

• Драйвер, который не требуется для загрузки системы и распознает устройство, не перечисляемое драйвером системной шины, указывает в Start значение, равное 1 (запуск системой). Пример — драйвер последовательного порта, информирующий диспетчер PnP о присутствии стандартных последовательных портов, которые были обнаружены программой Setup и зарегистрированы в реестре.

• Драйвер, не поддерживающий Plug and Play, или драйвер файловой системы, не обязательный для загрузки системы, устанавливает значение Start равным 2 (автозапуск). Пример — драйвер многосетевого UNC-npoвайдера (Multiple UNC Provider, MUP), поддерживающий UNC-имена удаленных ресурсов (вроде \\REMOTECOMPUTERNAME\SHARE).

• PnP-драйверы, не нужные для загрузки системы (например, драйверы сетевых адаптеров), указывают значение Start равным 3 (запуск по требованию). Единственное предназначение параметра Start для PnP-драйверов и драйверов перечисляемых устройств — загрузка драйвера с помощью загрузчика операционной системы, если такой драйвер обязателен для успешного запуска системы.

Перечисление устройств

Диспетчер PnP начинает перечисление устройств с виртуального драйвера шины с именем Root, который представляет всю систему и выступает в роли драйвера шины для драйверов, не поддерживающих Plug and Play, и для HAL.

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

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

По мере поступления сообщений от драйверов шин об обнаруженных устройствах, диспетчер PnP формирует внутреннее дерево, называемое деревом устройств (device tree) и отражающее взаимосвязи между устройствами. Узлы этого дерева называются узлами устройств (device nodes, devnodes). Узел устройств содержит информацию об объектах «устройство», представляющих устройства, и другую PnP-информацию, которая записывается в узел диспетчером PnP Упрощенный пример дерева устройств показан на рис. 9-25. Эта система ACPI-совместима, и поэтому перечислителем основной шины является ACPI-совместимый HAL. K основной шине PCI в данной системе подключены шины USB, ISA и SCSI.

Диспетчер устройств, доступный из оснастки Computer Management (Управление компьютером) и с вкладки Hardware (Оборудование) окна свойств системы, отображает простой список устройств в системе, сконфигурированной по умолчанию. Для просмотра устройств в виде иерархического дерева можно выбрать в меню View (Вид) диспетчера устройств команду Devices By Connection устройства по подключению). Рис. 9-26 иллюстрирует, как выглядит окно диспетчера устройств при выборе этой команды.

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

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

2. После инициализации драйверов, запускаемых при загрузке системы, диспетчер PnP проходит по дереву устройств, загружая драйверы для узлов устройств, не загруженных на первом этапе, и запускает их устройства. Запуская каждое устройство, диспетчер PnP перечисляет его дочерние устройства (если таковые есть). Для этого он запускает соответствующие драйверы и при необходимости перечисляет их дочерние устройства. Ha данном этапе диспетчер PnP загружает драйверы для обнаруженных устройств независимо om значений параметров Start этих драйверов (кроме тех драйверов, параметр Start которых содержит значение «отключен»). B конце этого этапа драйверы всех PnP-устройств загружены и запущены, кроме драйверов не перечисляемых устройств и их дочерних устройств.

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

4. Наконец, диспетчер управления сервисами (SCM) загружает автоматически запускаемые драйверы.

Дерево устройств используется диспетчерами PnP и электропитания в то время, когда они выдают устройствам IRP-пакеты, связанные с Plug and Play и управлением электропитанием. Как правило, поток IRP распространяется от верхней части узла устройств вниз, и иногда какой-либо драйвер в одном из узлов устройств создает новые IRP для передачи другим узлам (всегда в направлении корня). O потоках IRP-пакетов, связанных с Plug and Play и управлением электропитанием, мы поговорим позже.

ЭКСПЕРИМЕНТ: получаем дамп дерева устройств

Команда !devnode отладчика ядра позволяет более подробно изучить дерево устройств. Задав O и 1 в качестве параметров, вы получите дамп внутренних структур узлов этого дерева. При этом элементы структур выводятся с отступами, отражающими позиции элементов в общей иерархии.

Информация, показываемая для каждого узла устройств, включает InstancePath (имя подраздела для перечисленного устройства в HKLM\ SYSTEM\CurrentControlSet\Enum) и ServiceName (имя подраздела для драйвера устройства в HKLM\SYSTEM\CurrentControlSet\Services). Чтобы просмотреть такие ресурсы, как прерывания, порты и диапазоны памяти, назначенные каждому узлу устройств, используйте команду !devnode 0 3.

Все устройства, обнаруженные после установки системы, регистрируются в подразделах раздела реестра HKLM\SYSTEM\CurrentControlSet\Enum. Этим подразделам присваиваются имена в виде ‹Перечислителъ›\‹ID_устройства›\‹ID_экземпляра›, где перечислитель — драйвер шины, ID_ycmpouства — уникальный идентификатор устройств данного типа, а ID_экземпляра — уникальный идентификатор данного экземпляра этого устройства.

Узлы устройств

Узел устройств, который включает минимум два объекта «устройство», показан на рис. 9-27.

• Объект «физическое устройство» (physical device object, PDO) Создается драйвером шины по заданию диспетчера PnP, когда драйвер шины, перечисляя устройства на своей шине, сообщает о наличии какого-либо устройства. PDO представляет физический интерфейс устройства.

• Необязательные группы объектов-фильтров (filter device objects, FiDO) Одна группа таких объектов размещается между PDO и FDO (создается драйверами фильтров шин), вторая — между FDO и первой группой FiDO (создается низкоуровневыми драйверами фильтров), третья — над FDO (создается высокоуровневыми драйверами фильтров).

• Объект «функциональное устройство» (functional device object, FDO) Создается функциональным драйвером, который загружается диспетчером PnP для управления обнаруженным устройством. FDO представляет логический интерфейс устройства. Функциональный драйвер может выступать и в роли драйвера шины, если к устройству, представленному FDO, подключены другие устройства. Этот драйвер часто создает интерфейс к PDO, соответствующему данному FDO, что позволяет приложениям и другим драйверам открывать устройство и взаимодействовать с ним. Иногда функциональные драйверы подразделяются на драйвер класса, порт-драйвер и минипорт-драйвер, совместно управляющие вводом-выводом для FDO.

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

Загрузка драйверов для узла устройств

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

Ответ на оба вопроса надо искать в реестре. Перечисляя устройства, драйвер шины сообщает диспетчеру PnP идентификаторы обнаруженных устройств. Эти идентификаторы специфичны для конкретной шины. Например, для шины USB такой идентификатор состоит из идентификатора изготовителя (vendor ID, VID) и идентификатора продукта (product ID, PID), назначенного устройству изготовителем (подробнее о форматах идентификаторов устройств см. в DDK). B совокупности эти идентификаторы образуют то, что в терминологии спецификации Plug and Play называется идентификатором устройства (device ID). Диспетчер PnP также запрашивает у драйвера шины идентификатор экземпляра (instance ID), который позволяет различать отдельные экземпляры одного и того же устройства. Идентификатор экземпляра может определять устройство относительно шины (например, USB-порт) или представлять глобально уникальный дескриптор (скажем, серийный номер устройства). Идентификаторы устройства и экземпляра дают идентификатор экземпляра устройства (device instance ID, DIID), используемый диспетчером PnP для поиска раздела устройства в ветви реестра HKLM\SYSTEM\CurrentControlSet\Enum. Пример такого раздела для клавиатуры показан на рис. 9-28. B эти разделы помещаются данные, характеризующие устройство, и получаемые из INF-файла параметры Service и ClassGUID, с помощью которых диспетчер PnP находит драйверы, нужные для данного устройства.

ЭКСПЕРИМЕНТ: просмотр детальных сведений об узлах устройств в диспетчере устройств

По умолчанию апплет Device Manager (Диспетчер устройств), доступный с вкладки Hardware (Оборудование) окна свойств системы, не показывает детальных сведений об узле устройств. Однако в Windows XP и Windows Server 2003 вы можете активизировать вкладку Details (Сведения), создав переменную окружения devmgr_show_details и присвоив ей значение 1. Ha этой вкладке отображается целый набор полей, в том числе идентификатор экземпляра устройства для узла, имя сервиса, фильтры и возможности в управлении электропитанием.

Самый простой способ запустить диспетчер устройств с вкладкой Details — открыть окно командной строки и ввести:

C: \›set devmgr_show_details=1 C: \›devmgmt.msc

Ha следующем экранном снимке показано, как выглядит содержимое этой вкладки для одного из устройств.

Параметр ClassGUID позволяет диспетчеру PnP найти раздел класса устройства в HKLM\SYSTEM\CurrentControlSet\Control\Class. Раздел класса клавиатур показан на рис. 9-29. Раздел, созданный для устройства в процессе перечисления, и раздел класса предоставляют диспетчеру PnP всю информацию, на основе которой он загружает драйверы, необходимые для узла данного устройства. Загрузка драйверов происходит в следующем порядке.

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

2. Любые низкоуровневые драйверы фильтров, указанные в параметре Lo-werFilters раздела класса данного устройства.

3. Функциональный драйвер, заданный в параметре Service раздела, созданного для устройства в процессе перечисления. Значение этого параметра интерпретируется как имя раздела драйвера в HKLM\SYSTEM\CurrentControlSet\Services.

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

5. Любые высокоуровневые драйверы фильтров, указанные в параметре UpperFilters раздела класса данного устройства.

Ссылки на драйверы всегда содержат имена их разделов в HKLM\SYSTEM\ CurrentControlSet\Services.

ПРИМЕЧАНИЕ B DDK раздел, созданный для устройства в процессе перечисления, называется аппаратным (hardware key), а раздел класса — программным (software key).

Устройство «клавиатура», представленное на рис. 9-28 и 9-29, не имеет низкоуровневых драйверов фильтров. Его функциональный драйвер — i8042prt; в разделе класса клавиатур указано два высокоуровневых драйвера фильтров — kbdclass и ctrl2cap.

Установка драйвера

Если диспетчер PnP встречает устройство, драйвер которого не установлен, он обращается к диспетчеру PnP пользовательского режима, и тот устанавливает нужный драйвер. Если устройство обнаруживается при загрузке системы, для него определяется узел устройств, но загрузка драйверов откладывается до запуска диспетчера PnP пользовательского режима (он реализован в \Windows\System32\Umpnpmgr.dll и выполняется как сервис в процессе Services.exe).

Компоненты, участвующие в установке драйвера, показаны на рис. 9-30. Серые блоки на этом рисунке соответствуют компонентам, обычно предоставляемым системой, а остальные блоки — компонентам, предоставляемым установочными файлами. Сначала драйвер шины информирует диспетчер PnP о перечисленном устройстве, сообщая его DIID (1). Диспетчер PnP проверяет, определен ли в реестре подходящий функциональный драйвер. Если нет, он уведомляет диспетчер PnP пользовательского режима (2) о новом устройстве, сообщая его DIID. Диспетчер PnP пользовательского режима пытается автоматически установить драйверы для устройства. Если в процессе установки выводятся диалоговые окна, требующие внимания пользователя, а зарегистрированный в данный момент пользователь имеет привилегии администратора (3), то диспетчер PnP пользовательского режима запускает Rundll32.exe (хост-программу апплетов Control Panel) для выполнения мастера установки оборудования (\Windows\System32\Newdev.dll). Если зарегистрированный в данный момент пользователь не имеет привилегий администратора (или в системе нет пользователей), а установка устройства требует взаимодействия с пользователем, диспетчер PnP пользовательского режима откладывает установку до того момента, когда в систему войдет привилегированный пользователь. Для поиска INF-файлов, соответствующих драйверам, совместимым с обнаруженным устройством, мастер установки оборудования использует API-функции Setup и CfgMgr (диспетчера конфигурации). При этом пользователю может быть предложено вставить в один из дисководов носитель с нужными INF-файлами; кроме того, просматриваются INF-файлы в \Windows\Driver Cache\i386\Driver.cab, где содержатся драйверы, поставляемые с Windows.

Чтобы найти драйверы для нового устройства, процесс установки получает от драйвера шины список идентификаторов оборудования (hardware ID) и идентификаторов совместимых устройств (compatible ID). Эти идентификаторы описывают все способы, предусмотренные в установочном файле драйвера (INF-файле) для идентификации устройства. Списки упорядочиваются так, чтобы наиболее специфические характеристики устройства описывались первыми. Если совпадения идентификаторов обнаруживаются в нескольких INF-файлах, предпочтение отдается наиболее полным совпадениям. Аналогичным образом предпочтение отдается INF-файлам с цифровой подписью, а среди них — более новым. Если найденный идентификатор соответствует идентификатору совместимого устройства, мастер установки оборудования может запросить носитель с обновленными драйверами для этого устройства.

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

ЭКСПЕРИМЕНТ: просмотр INF-файла драйвера

При установке драйвера или другого программного обеспечения, у которого есть INF-файл, система копирует этот файл в каталог \Win-dows\Inf. Один из файлов, которые всегда будут в этом каталоге, — Keyboard.inf, поскольку это INF-файл для драйвера класса клавиатур. Просмотрите его содержимое, открыв в Notepad. Вы должны увидеть нечто вроде:

; Copyright (с) 1993–1996, Microsoft Corporation

[version]

signature="$Windows NT$" Class=Keyboard

ClassGUID={4D36E96B-E325-11CE-BFC1-08002BE10318}

Provider=XMSX

LayoutFile=layout.inf

DriverVer=07/01/2001, 5.1.2600.1106

[ClassInstall32.NT] AddReg=keyboa rd_class_add reg

Если вы проведете поиск в этом файле по «.sys», то обнаружите запись, указывающую диспетчеру PnP пользовательского режима установить драйверы i8042prt.sys и kbdclass.sys:

[STANDARD_CopyFiles]

i8042prt.sys kbdclass.sys

Перед установкой драйвера диспетчер PnP пользовательского режима проверяет системную политику проверки цифровых подписей в драйверах. Эта политика хранится в разделе реестра HKLM\SOFTWARE\Microsoft\Driver Signing\Policy, если администратор выбрал общесистемную политику, или в HKCU\Software\Microsoft\Driver Signing\Policy, если в системе применяются политики только по отношению к индивидуальным пользователям. Политика проверки цифровых подписей в драйверах настраивается через диалоговое окно Driver Signing Options (Параметры подписывания драйвера), доступное с вкладки Hardware (Оборудование) окна свойств системы (рис. 9-31). Если указанные параметры заставляют систему блокировать установку неподписанных драйверов или предупреждать о таких попытках, диспетчер PnP пользовательского режима проверяет в INF-файле драйвера запись, указывающую на каталог (файл с расширением. cat), где содержится цифровая подпись драйвера.

Рис. 9-31. Параметры проверки цифровых подписей в драйверах

Лаборатория Microsoft WHQL тестирует драйверы, поставляемые с Windows и предлагаемые изготовителями оборудования. Драйвер, прошедший тесты WHQL, «подписывается» Microsoft. Это означает, что создается хэш, или уникальное значение, представляющее файлы драйвера, в том числе его образ, а затем этот хэш подписывается с применением закрытого ключа Microsoft, предназначенного для подписания драйверов. Подписанный хэш помещается в САТ-файл и записывается на дистрибутив Windows или передается изготовителю, который включает его в свой драйвер.

ЭКСПЕРИМЕНТ: просмотр САТ-файлов

При установке компонента, например драйвера, файлы которого включают САТ-файл, Windows копирует этот файл в подкаталог каталога \Windows\System32\Catroot. Перейдите в этот каталог с помощью Explorer и найдите подкаталог с САТ-файлами. B частности, в Nt5.cat и Nt5inf.cat хранятся подписи для системных файлов Windows.

Открыв один из САТ-файлов, вы увидите диалоговое окно с двумя вкладками: General (Общие), на которой показывается информация о подписи в данном файле, и Security Catalog (Каталог безопасности), где представлены хэши компонентов, подписанных с использованием этого САТ-файла. Ниже дан пример САТ-файла для видеодрайверов ATI, где приведено содержимое хэша для минипорт-драйверов видеоадаптера. Остальные хэши в этом файле относятся к вспомогательным DLL, поставляемым с данными драйверами.

При установке драйвера диспетчер PnP пользовательского режима извлекает из САТ-файла подпись драйвера, расшифровывает ее с применением открытого ключа Microsoft и сравнивает полученный в результате хэш с хэшем файла устанавливаемого драйвера. Если хэши совпадают, драйвер считается проверенным на соответствие требованиям WHQL. Если проверка заканчивается неудачно, диспетчер PnP пользовательского режима действует так, как это диктует действующая политика: запрещает установку, предупреждает пользователя о том, что драйвер не подписан, или автоматически устанавливает драйвер.

ПРИМЕЧАНИЕ Наличие подписей у драйверов, устанавливаемых программами установки, которые самостоятельно настраивают реестр и копируют файлы драйвера в систему, а также у драйверов, динамически загружаемых приложениями, не проверяется. Политика проверки подписей драйверов распространяется только на драйверы, устанавливаемые с помощью INF-файлов.

После установки драйвера диспетчер PnP режима ядра (этап 5 на рис. 9-30) запускает драйвер и вызывает его процедуру добавления устройства, чтобы уведомить драйвер о присутствии устройства, для управления которым он был загружен. Далее формируется узел устройства, как мы уже объясняли.

ПРИМЕЧАНИЕ B Windows XP и Windows Server 2003 диспетчер PnP пользовательского режима также проверяет, не включен ли устанавливаемый драйвер в защищенный список драйверов (protected driver list), поддерживаемых Windows Update, и, если включен, блокирует установку с выводом предупреждения для пользователя. B этот список вносятся драйверы, которые имеют известные ошибки или просто несовместимы, и их установка блокируется. Детали см. по ссылке www.micro- soft.com/whdc/winlogo/drvsign/drv_protect.mspx.

Диспетчер электропитания

Как и PnP-функции Windows, управление электропитанием требует аппаратной поддержки. Она должна отвечать спецификации Advanced Configuration and Power Interface (ACPI) (см. www.teleport.com/acpi/spechtm). Согласно этой спецификации BIOS (Basic Input Output System) тоже должна соответствовать стандарту ACPI. Этим требованиям удовлетворяет большинство x86-компьютеров, выпускавшихся с конца 1998 года.

ПРИМЕЧАНИЕ Некоторые компьютеры — особенно те, которые были изготовлены несколько лет назад, — не полностью совместимы со стандартом ACPI. Они соответствуют более старому стандарту Advanced Power Management (АРМ), определяющему меньшее количество функций управления электропитанием, чем ACPI. Windows поддерживает ограниченный набор функций управления электропитанием для АРМ-систем, но мы не будем вдаваться в детали этого стандарта и основное внимание уделим поведению Windows, установленной на ACPI-совместимых компьютерах.

Стандарт ACPI определяет различные уровни энергопотребления для системы и устройств. Шесть состояний для системы — от SO (полностью активное, или рабочее, состояние) до S5 (полное отключение) — перечислены в таблице 9–3. Каждое из них характеризуется следующими параметрами.

• Энергопотребление (power consumption) Количество энергии, потребляемой компьютером.

• Возобновление работы ПО (software resumption) Состояние программного обеспечения при переходе компьютера в «более активное» состояние.

• Аппаратная задержка (hardware latency) Время, необходимое на то, чтобы вернуть компьютер в полностью активное состояние.

B состояния ожидания (S1 — S4) компьютер кажется отключенным, так как потребляет меньше энергии. Ho при этом он сохраняет и в памяти, и на диске всю информацию, необходимую для возврата в состояние S0. B состояниях S1-S3 для сохранения содержимого памяти нужно достаточное количество энергии, поскольку при переходе в S0 (при пробуждении компьютера пользователем или устройством) диспетчер электропитания возобновляет работу системы с той точки, где оно было прервано. Когда система переходит в состояние S4, диспетчер электропитания сохраняет содержимое памяти в сжатой форме в файле спящего режима (Hiberfil.sys), который помещается в корневой каталог системного тома. (Этот файл должен быть такого размера, чтобы в нем могло уместиться несжатое содержимое всей памяти; сжатие используется для того, чтобы свести к минимуму операции ввода-вывода на диске, а также ускорить переход в спящий режим и выход из него.) Сохранив содержимое памяти, диспетчер электропитания отключает компьютер. При последующем включении компьютера происходит обычный процесс загрузки — с тем исключением, что Ntldr проверяет наличие действительного образа памяти, сохраненного в файле спящего режима. Если в этом файле сохранены данные о состоянии системы, Ntldr считывает его содержимое в память и возобновляет выполнение с точки, зафиксированной в Hiberfil.sys.

Компьютер никогда не переходит напрямую между состояниями S1 и S4, для этого ему нужно сначала перейти в состояние S0. Как показано на рис. 9-32, переход системы из состояний S1-S5 в состояние S0, называется пробуждением (waking), а переход из состояния SO в состояния Sl-S5 — переходом в сон (sleeping).

Хотя система может пребывать в одном из шести состояний энергопотребления, ACPI определяет для устройств четыре состояния: D0-D3. B состоянии DO устройство полностью включено, а в состоянии D3 полностью отключено. ACPI позволяет драйверам и устройствам самостоятельно определять состояния Dl и D2 с единственным условием, что устройство в состоянии D1 должно потреблять столько же или меньше энергии, чем в состоянии D0, а в состоянии D2 — столько же или меньше, чем в состоянии D1. Microsoft совместно с крупными OEM-производителями определила набор спецификаций управления электропитанием (см. www.microsoft.com/whdc/resources/respec/ specs/pmref), в которых описываются состояния энергопотребления для всех устройств конкретного класса (основные классы устройств: видеоадаптеры, сеть, SCSI и т. д.). Некоторые устройства могут быть лишь включены или выключены, поэтому для них промежуточные состояния не определены.

Работа диспетчера электропитания

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

• уровня активности системы;

• уровня заряда аккумуляторов;

• наличия запросов приложений на выключение компьютера или переход в ждущий/спящий режим;

• действий пользователя, например нажатия кнопки включения электропитания;

• параметров электропитания, заданных в Control Panel.

Часть информации, получаемой диспетчером PnP при перечислении устройств, связана с поддержкой устройствами функций управления электропитанием. Драйвер сообщает, поддерживает ли устройство состояния D1 и D2, а также какие задержки требуются ему для перехода из состояний D1-D3 в D0 (последняя часть данных необязательна). Чтобы диспетчеру было легче определять, когда систему следует переводить в другое состояние энергопотребления, драйверы шин также возвращают таблицу сопоставлений между системными состояниями (S0-S5) и состояниями, поддерживаемыми конкретным устройством. B этой таблице указывается состояние устройства с наименьшим энергопотреблением для каждого системного состояния. B таблице 9–4 показан пример таблицы сопоставлений для шины, поддерживающей все четыре возможных состояния устройств. Большинство драйверов полностью выключают свои устройства (D3) при выходе системы из состояния S0, чтобы свести к минимуму энергопотребление, пока машина не используется. Однако некоторые устройства вроде сетевых адаптеров поддерживают функцию вывода системы из состояний сна. O наличии подобной функции также сообщается при перечислении устройств.

Участие драйверов в управлении электропитанием

Диспетчер электропитания, принимая решение о переходе системы в другое состояние, посылает команды процедуре драйвера, отвечающей за диспетчеризацию электропитания. Управлять устройством могут несколько драйверов, но только один из них является владельцем политики управления электропитанием устройства. Этот драйвер определяет состояние устройства в зависимости от состояния энергопотребления системы. Например, при переходе системы из состояния S0 в состояние S1 драйвер может принять решение о переводе устройства из состояния D0 в состояние D1. Вместо того чтобы напрямую оповещать об этом другие драйверы, участвующие в управлении устройством, владелец политики управления электропитанием устройства делает это через диспетчер электропитания, вызывая функцию PoRequestPowerIrp.

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

ЭКСПЕРИМЕНТ: просмотр сопоставлений состояний электропитания в драйвере

B Windows XP и Windows Server 2003 это можно сделать с помощью диспетчера устройств. Откройте окно свойств для какого-либо устройства и выберите запись Power State Mappings (Сопоставления энергосбережения) в раскрывающемся списке на вкладке Details (Сведения). (По умолчанию диспетчер устройств не показывает эту вкладку. Как ее включить, см. в эксперименте «просмотр детальных сведений об узлах устройств в диспетчере устройств» ранее в этой главе.)

Ha иллюстрации ниже показаны такие сопоставления для драйвера диска. Кроме состояний DO (полное включение) и D3 (полное отключение), он поддерживает промежуточное состояние D1, сопоставленное с S1.

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

ЭКСПЕРИМЕНТ: просмотр возможностей и системной политики управления электропитанием

Вы можете выяснить возможности своего компьютера в управлении электропитанием с помощью команды !pocaps отладчика ядра. Ниже приведен пример вывода этой команды для ACPI-совместимого портативного компьютера с Windows Professional.

Строка Misc Supported Features сообщает, что кроме SO данная система поддерживает состояния S1, S3, S4 и S5 (S2 не реализовано) и имеет действительный файл спящего режима, в который можно сохранить содержимое системной памяти при переходе в спящий режим (состояние S4).

Диалоговое окно Power Options Properties (Свойства: Электропитание), показанное на следующей иллюстрации (оно открывается через Control Panel), позволяет настроить различные аспекты системной политики управления электропитанием. Конкретные параметры, доступные для настройки, зависят от степени поддержки системой функций управления электропитанием.

ACPI-совместимый портативный компьютер с Windows Professional или Home предоставляет максимум возможностей в управлении электропитанием. B таких системах можно установить интервалы простоя, по истечении которых отключается монитор, останавливаются жесткие диски и осуществляется переход в ждущий (состояние Sl) и спящий режимы (состояние S4). Кроме того, вкладка Advanced (Дополнительно) в диалоговом окне Power Options Properties позволяет указать поведение системы при нажатии кнопок включения электропитания и перехода в спящий режим, а также при закрытии крышки ноутбука.

Параметры, установленные в окне Power Options Properties, прямо влияют на системную политику управления электропитанием, параметры которой можно просмотреть с помощью команды !popolicy отладчика ядра. Вот как выглядит информация, сообщаемая этой командой для той же системы:

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

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

Как драйвер управляет электропитанием устройства

Драйвер не только отвечает на команды диспетчера электропитания, связанные с изменением состояния системы, но и может сам управлять состоянием энергопотребления своих устройств. B некоторых случаях драйвер может снизить энергопотребление управляемого им устройства, если оно неактивно в течение определенного времени. Драйвер может обнаруживать простаивающие устройства самостоятельно или через механизмы, предоставляемые диспетчером электропитания. Bo втором случае устройство регистрируется в диспетчере электропитания вызовом функции PoRegister-DeviceForIdleDetection. Эта функция сообщает диспетчеру электропитания пороговые интервалы простоя устройства и указывает, в какое состояние следует переводить устройство, если оно простаивает. Драйвер задает два таймаута: первый — для энергосберегающей конфигурации, второй — для максимально производительной. Вызвав PoRegisterDeviceForIdleDetection, драйвер должен уведомлять диспетчер электропитания об активности устройства через функцию PoSetDeviceBusy.

Резюме

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

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

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

Следующие четыре главы мы посвятим смежной тематике: управлению устройствами внешней памяти, файловым системам (особое внимание будет уделено NTFS), диспетчеру кэша и поддержке сетей.

База данных LDM размещается в зарезервированном пространстве (размером 1 Мб) в конце каждого динамического диска. Именно поэтому Windows требует свободное место в конце базового диска при его преобразовании в динамический. База данных LDM состоит из четырех областей, показанных на рис. 10-5: сектора заголовка, называемого в LDM «Private Header», таблицы оглавления, записей базы данных и журнала транзакций (пятый раздел на рис. 10-5 — просто зеркальная копия Private Header). Сектор Private Header размещается за 1 Мб до конца динамического диска и является границей базы данных. Работая с Windows, вы быстро заметите, что для идентификации практически всех объектов в ней используются GUID, и диски не составляют исключения. GUID — это 128-битное число, применяемое различными компонентами Windows для уникальной идентификации объектов. LDM назначает GUID каждому динамическому диску, а сектор Private Header регистрирует GUID динамического диска, на котором он находится, поэтому данные в Private Header относятся исключительно к конкретному диску. Private Header также хранит указатель на начало таблицы оглавления базы данных и имя дисковой группы, которое формируется конкатенацией имени компьютера и строки Dg0 (если имя компьютера — Daryl, то имя дисковой группы — DarylDg0). (Как уже говорилось, LDM в Windows поддерживает только одну дисковую группу, поэтому ее имя всегда оканчивается на DgO.) Для большей надежности LDM поддерживает копию Private Header в последнем секторе диска.

Таблица оглавления занимает 16 секторов и содержит информацию о структуре базы данных. Область записей базы данных LDM начинается с сектора заголовка записей базы данных сразу за таблицей оглавления. B этом секторе хранится информация об области записей базы данных, включая число присутствующих в ней записей, имя и GUID дисковой группы, к которой относится база данных, и идентификатор последовательности, используемый LDM для создания следующего элемента в базе данных. Секторы, следующие за сектором заголовка записей, содержат записи фиксированного размера (по 128 байтов) с описанием разделов и томов дисковой группы.

Элементы базы данных могут быть четырех типов: раздел (partition), диск (disk), компонент (component) и том (volume). Типы элементов определяют три уровня описания томов. LDM связывает элементы с помощью внутренних идентификаторов объектов. Ha самом нижнем уровне элементы разделов (partition entries) описывают нежесткие разделы, которые являются непрерывными областями на диске; идентификаторы, хранящиеся в элементе раздела, связывают его с элементами компонентов и дисков. Элемент диска (disk entry) представляет динамический диск в составе группы и включает его GUID. Элемент компонента (component entry) служит связующим звеном между одним или несколькими элементами разделов и элементом тома, с которым сопоставлен каждый раздел. Элемент тома хранит GUID этого тома, его суммарный размер, информацию о состоянии и букву диска. Элементы дисков, размер которых превышает размер одной записи, занимают несколько записей; элементы разделов, компонентов и томов редко занимают больше одной записи.

Простой том в LDM описывается тремя элементами: раздела, компонента и тома. Ниже показано содержимое простой базы данных LDM, которая определяет один том размером 200 Мб, состоящий из одного раздела.

Элемент раздела описывает область на диске, отведенную тому, элемент компонента связывает элемент раздела с элементом тома, а элемент тома содержит GIUD, используемый Windows на внутреннем уровне для идентификации тома. Для составных томов требуется более трех элементов. Например, чередующийся том (о них — позже) состоит минимум из двух элементов разделов, элемента компонента и элемента тома. Единственный том, который включает более одного элемента компонента, — зеркальный. Зеркальные тома включают два элемента компонентов, каждый из которых представляет половину зеркального тома. Когда вы разбиваете зеркальный том на разделы, LDM может разделить его на уровне компонентов, создав два тома, в каждом из которых будет по одному элементу компонента.

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

ЭКСПЕРИМЕНТ: просмотр базы данных LDM с помощью LDMDump

Утилита LDMDump (от Sysinternals) позволяет получить детальную информацию о содержимом базы данных LDM. Она принимает номер диска в качестве аргумента командной строки. Выводимая ею информация занимает несколько экранов, поэтому ее следует перенаправить в файл для последующего просмотра в текстовом редакторе (например: ldmdump /d0 › disk.txt). Ниже даны фрагменты выходной информации LDMDump. Первым показывается заголовок базы данных LDM, затем записи этой базы данных, которые описывают 4-гигабайтный диск с простым томом размером в 4 Гб. Элемент тома базы данных обозначен KaKVolumel. B конце вывода LDMDump перечисляет нежесткие разделы (soft partitions) и определения томов, найденные в базе данных.

Схемы разбиения на разделы LDM и GPT или MBR

Одно из первых действий при установке Windows на компьютер — создание раздела на основном физическом диске системы. B этом разделе Windows определяет системный том для хранения файлов, нужных на ранних этапах процесса загрузки. Кроме того, Windows Setup требует создать раздел для загрузочного тома, в который она запишет системные файлы Windows и где будет создан системный каталог (\Windows). Системный том можно сделать и загрузочным — тогда вам не понадобится создавать новый раздел для загрузочного тома. Терминология, используемая Microsoft для системного и загрузочного томов, может сбить с толку. Системным считается том, на который Windows помещает загрузочные файлы, включая загрузчик (Ntldr) и Ntdetect, а загрузочным — том, на котором Windows хранит основные системные файлы вроде Ntoskrnl.exe.

Хотя данные о разбиении динамического диска на разделы находятся в базе данных, LDM реализует и таблицу разделов в стиле MBR или GPT, чтобы загрузочный код Windows мог найти системный и загрузочный тома на динамических дисках. (Например, Ntldr и микрокод IA64 ничего не знают о LDM-разделах.) Если диск содержит системный и/или загрузочный тома, они описываются в таблице разделов в стиле MBR или GPT. B ином случае один раздел охватывает всю доступную для использования область диска. LDM помечает его как раздел типа «LDM»; поддержка разделов этого типа впервые появилась в Windows 2000. B пространстве, определенном в стиле MBR или GPT, LDM создает разделы, организуемые базой данных LDM.

Еще одна причина, по которой LDM создает таблицу разделов в стиле MBR или GPT, — чтобы унаследованные утилиты обслуживания дисков, включая работающие в средах с двухвариантной загрузкой, не решили, будто на динамическом диске не определены разделы.

Поскольку LDM-разделы не описываются таблицей разделов в стиле MBR или GPT, они называются нежесткими (soft partitions), а разделы в стиле MBR или GPT — жесткими (hard partitions). Рис. 10-6 иллюстрирует структуру динамического диска, размеченного в стиле MBR.

Диспетчер томов на динамических дисках

DLL оснастки Disk Management (DMDiskManager в Windows\System32\Dmdskmgr.dll), показанной на рис. 10-7, использует DMAdmin, службу LDM Disk Administrator (Windows\System32\Dmadmin.exe) для создания базы данных LDM и изменения ее содержимого. Когда вы запускаете оснастку Disk Management, в память загружается DMDiskManager, который запускает DMAdmin, если она еще не выполняется. DMAdmin считывает с каждого диска базу данных LDM и возвращает полученную информацию DMDiskManager. Если DMAdmin обнаруживает базу данных из дисковой группы другого компьютера, то отмечает, что эти тома находятся на удаленном диске, и позволяет импортировать их в базу данных текущего компьютера, если вы хотите их использовать. При изменении конфигурации динамических дисков DMDiskManager информирует DMAdmin о внесенных изменениях, и DMAdmin обновляет свою копию базы данных в памяти. Зафиксировав изменения, DMAdmin передает обновленную базу данных DMIO, драйверу устройства Dmio.sys. DMIO — эквивалент FtDisk для динамических дисков, так что он управляет доступом к базе данных на диске и создает объекты «устройство», представляющие тома на динамических дисках. Когда вы закрываете оснастку Disk Management, DMDiskManager останавливает и выгружает службу DMAdmin.

DMIO не знает, как интерпретировать базу данных, которой он управляет. За интерпретацию базы данных отвечают DMConfig (Windows\System32\ Dmconfig.dll), загружаемый DMAdmin, и DMBoot (Dmboot.sys), еще один драйвер устройства. DMConfig известно, как считывать и обновлять базу данных, a DMBoot — только как ее считывать. DMBoot загружается при загрузке системы, если другой драйвер LDM, DMLoad (Dmload.sys), обнаруживает в системе минимум один динамический диск. DMLoad определяет наличие динамических дисков, запрашивая DMIO. Если в системе есть хотя бы один динамический диск, DMLoad запускает DMBoot, который сканирует базу данных LDM. DMBoot информирует DMIO о составе каждого найденного им тома, что позволяет DMIO создать объекты «устройство» для представления томов. Закончив сканирование, DMBoot тут же выгружается из памяти. Поскольку в DMIO не заложена логика для интерпретации базы данных, его размер относительно невелик. Это несомненное преимущество, так как DMIO постоянно находится в памяти.

Как и FtDisk, DMIO является драйвером шины и создает объект «устройство» для каждого тома динамического диска, присваивая ему имя в виде \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolumeX, где Х- идентификатор тома, назначаемый DMIO. Кроме того, DMIO создает объект «устройство» с именем \Device\HarddiskDmVolumes\PhysicalDmVolumes\Raw-VolumeX, который представляет необработанный (неструктурированный) ввод-вывод на томе. Объекты «устройство», созданные DMIO в системе с тремя томами на динамических дисках, показаны на рис. 10-8. DMIO также создает в пространстве имен диспетчера объектов символьные ссылки на все тома, в том числе по одной ссылке для каждого тома в виде \Device\HarddiskDmVolumes\ComputerNameDg0\VolumeY. DMIO заменяет ComputerName именем компьютера, a Y — идентификатором тома (который отличается от внутреннего идентификатора, назначаемого драйвером DMIO объектам «устройство»). Эти ссылки указывают на объекты блочных устройств в каталоге PhysicalDmVolumes.

ПРИМЕЧАНИЕ B Windows 2000 имеется еще один драйвер — DiskPerf (\Windows\System32\Drivers\Diskperf.sys); он подключается к объектам «устройство», представляющим физические устройства (например, к \Device\Harddisk0\Partition0), что позволяет ему отслеживать запросы ввода-вывода, адресованные дискам, и генерировать статистические данные для соответствующих счетчиков оснастки Performance. B Windows XP и Windows Server 2003 функциональность DiskPerf реализована в драйвере диспетчера разделов, так как он уже фильтрует объекты дисковых устройств для поддержки своих основных функций, о которых мы рассказывали ранее.

Управление составными томами

FtDisk и DMIO отвечают за представление томов, управляемых драйверами файловой системы, и за перенаправление ввода-вывода, адресованного томам, в нижележащие разделы, составляющие тома. B случае простых томов диспетчер томов преобразует смещение в томе в смещение на диске, суммируя смещение в томе со смещением тома от начала диска.

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

B Windows поддерживаются следующие типы составных томов:

• перекрытые (spanned volumes);

• зеркальные (mirrored volumes);

• чередующиеся (striped volumes);

• RAID-5.

Рассмотрев конфигурацию разделов составных томов и логические операции для каждого типа составных томов, мы обсудим, как драйверы FtDisk и DMIO обрабатывают IRP, посылаемые драйвером файловой системы составному тому Термин «диспетчер томов» при объяснении составных томов используется для обозначения DMIO, поскольку, как уже говорилось в этой главе, FtDisk поддерживает лишь те составные тома, которые были перенесены из NT 4.

Перекрытые тома

Перекрытый том — единый логический том, состоящий из нескольких (до 32) свободных разделов на одном или нескольких дисках. Оснастка Disk Management (Управление дисками) консоли MMC объединяет разделы в перекрытый том, который затем можно отформатировать для любой файловой системы, поддерживаемой Windows. Ha рис. 10-9 показан 100-мегабайтный перекрытый том с именем D:, созданный из последней трети первого диска и первой трети второго диска. B Windows NT 4 перекрытые тома назывались наборами томов (volume sets).

Перекрытый том удобен для объединения небольших областей свободного дискового пространства в единый том большего объема или для создания из нескольких малых дисков одного большого тома. Если перекрытый том отформатирован для NTFS, его можно расширять, добавляя другие свободные области или диски, и это не влияет на данные, уже хранящиеся на томе. Расширяемость — одно из самых крупных преимуществ описания всех данных на томе NTFS как единого файла. Размер логического тома NTFS может динамически увеличиваться, поскольку битовая карта, регистрирующая состояние тома, — не более чем еще один файл, файл битовой карты. Этот файл может быть расширен для учета пространства, добавляемого в том. C другой стороны, динамическое расширение тома FAT потребовало бы расширения самой FAT, что привело бы к смещению всех данных на диске.

Диспетчер томов скрывает физическую конфигурацию дисков от файловых систем, установленных в Windows. Например, на рис. 10-9 файловая система NTFS рассматривает том D: как обыкновенный 100-мегабайтный том. Чтобы определить свободное пространство на этом томе, NTFS обращается к своей битовой карте. Далее она вызывает диспетчер томов для чтения или записи данных с конкретного смещения в байтах относительно начала тома. Диспетчер томов последовательно нумерует физические секторы перекрытого тома от первой области первого диска до последней области последнего диска. Он определяет, какой физический сектор и на каком диске соответствует указанному смещению.

Чередующиеся тома

Чередующийся том — группа разделов (до 32), каждый из которых размещается на отдельном диске и объединяется в один логический том. Чередующиеся тома также называются томами RAID уровня 0, или томами RAID-0. Ha рис. 10–10 показан чередующийся том, состоящий из трех разделов, каждый из которых находится на отдельном диске. (Раздел чередующегося тома не обязательно занимает весь диск; единственное ограничение — все разделы на каждом диске должны быть одинаковы.)

Файловой системе этот чередующийся том кажется обычным 450-мегабайтным томом, но диспетчер томов оптимизирует хранение и выборку данных па таком томе, распределяя их между физическими дисками. Диспетчер томов обращается к физическим секторам дисков так, как показано на рис. 10–11.

Рис. 10–11. Логическая нумерация физических секторов в чередующихся томах

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

Чередующиеся тома упрощают управление томами и позволяют распределять нагрузку между несколькими дисками, значительно ускоряя ввод-вывод. Ho это не обеспечивает восстановления данных в случае сбоя диска. B связи с этим диспетчер томов реализует три механизма избыточности: зеркальные тома, тома RAID-5 и замена секторов (последний механизм описывается в главе 12). Эти возможности можно задействовать через оснастку Disk Management.

Зеркальные тома

B зеркальном томе содержимое раздела на одном диске дублируется в разделе равного размера на другом диске (рис. 10–12). Такие тома иногда называют томами RAID уровня 1, или томами RAID-1.

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

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

Зеркальный том — единственный тип составного тома, допустимого для системного и загрузочного томов. Дело в том, что загрузочный код Windows, включая код MBR и Ntldr, не обладает сложной логикой, необходимой для работы с составными томами. Зеркальные тома составляют исключение, так как загрузочный код воспринимает их как простые тома, считывая данные с той половины зеркального тома, которая помечена как загрузочный или системный диск в таблице разделов MBR. Поскольку загрузочный код не модифицирует данные на диске, он может игнорировать вторую половину зеркального тома.

ЭКСПЕРИМЕНТ: наблюдаем за операциями ввода-вывода на зеркальном томе

Используя оснастку Performance (Производительность), вы можете убедиться, что при записи на зеркальные тома данные копируются на оба диска, составляющих зеркальный том (зеркало), а операции чтения, если они не слишком частые, выполняются в основном на одной из половин зеркального тома. Для этого эксперимента вам понадобится система с тремя жесткими дисками под управлением серверной OC Windows 2000 или Windows Server 2003- Если у вас нет такой системы, пропустите инструкции по подготовке эксперимента и переходите сразу к результатам.

Создайте зеркальный том с помощью оснастки Disk Management.

1. Запустите Computer Management (Управление компьютером), раскройте узел Storage (Запоминающие устройства) и выберите папку Disk Management (Управление дисками) или откройте Disk Management как оснастку консоли MMC

2. Щелкните правой кнопкой мыши на свободном пространстве диска и выберите команду Create Volume (Создать том).

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

4. Щелкните правой кнопкой мыши новый том и из контекстного меню выберите команду Add Mirror (Добавить зеркало).

Создав зеркальный том, запустите оснастку Performance (Производительность) и добавьте счетчики к объекту PhysicalDisk (Физический диск) для каждого экземпляра диска, содержащего раздел зеркального тома. Выберите счетчики Disk Reads/Sec (Обращений чтения с диска/сек) и Disk Writes/Sec (Обращений записи на диск/сек). Ha третьем диске, не входящем в состав зеркального тома, выберите большой каталог и скопируйте его на зеркальный том. Информация в окне оснастки Performance по мере выполнения операции копирования должна выглядеть примерно так, как показано на иллюстрации.

Две верхних пересекающихся линии представляют графики для значений Disk Writes/Sec по каждому диску, а две нижних — графики для значений Disk Reads/Sec. Как видите, диспетчер томов (в данном случае — DMIO) записывает данные копируемых файлов в обе половины тома, но считывает преимущественно из одной. Это происходит потому, что число незавершенных операций ввода-вывода при копировании невелико и не заставляет диспетчер томов распределять нагрузку по операциям чтения между дисками.

Тома RAID-5

Том RAID-5 — отказоустойчивый вариант обычного чередующегося тома. B томах RAID-5 реализуется RAID уровня 5. Эти тома также называются чередующимися томами с записью четности (striped volumes with parity), поскольку они основаны на том же принципе чередования. Отказоустойчивость достигается за счет резервирования эквивалента одного диска для хранения информации о четности для всех чередующихся областей. Том RAID-5 представлен на рис. 10–13.

Как показано на рис. 10–13, информация о четности для чередующейся области 1 хранится на диске 1. Она представляет собой побайтовую логическую сумму (XOR) первых чередующихся областей на дисках 2 и 3. Информация о четности для чередующейся области 2 хранится на диске 2, а для чередующейся области 3 — на диске 3. Такое циклическое размещение информации о четности по дискам представляет собой способ оптимизации ввода-вывода. Всякий раз, когда данные записываются на какой-либо из дисков, байты четности, соответствующие изменяемым байтам, должны быть пересчитаны и перезаписаны. Если бы информация о четности постоянно записывалась на один и тот же диск, он был бы все время занят и мог бы стать узким местом для ввода-вывода.

Восстановление диска после сбоя в томе RAID-5 основывается на простом арифметическом принципе: если в уравнении с n переменными известны значения n — 1 переменных, то значение оставшейся переменной можно определить вычитанием. Например, в выражении x +y = z, где z обозначает чередующуюся область с четностью, диспетчер томов вычисляет z — у, чтобы определить значение x, и z — x, чтобы найти y. Диспетчер томов использует сходную логику для восстановления потерянных данных. Если том RAID-5 выходит из строя или данные на одном из его дисков становятся нечитаемыми, диспетчер томов реконструирует отсутствующие данные, используя операцию XOR (побитовое логическое сложение).

B случае сбоя диска 1 на рис. 10–13 содержимое его чередующихся областей 2 и 5 вычисляется побайтовым логическим сложением соответствующих чередующихся областей на диске 3 с областями четности на диске 2. Содержимое чередующихся областей 3 и 6 определяется побайтовым логическим сложением соответствующих областей на диске 2 с областями четности на диске 3. Для организации тома RAID-5 требуется по крайней мере три диска (а точнее, три одинаковых по размеру раздела на трех дисках).

Пространство имен томов

Такой аспект управления внешней памятью, как назначение томам букв дисков, в Windows существенно изменился по сравнению с Windows NT 4. Несмотря на это, Windows поддерживает назначения букв, переносимые при обновлении системы с Windows NT 4 до Windows. Назначенные буквы Windows NT 4 хранит в разделе реестра HKLM\SYSTEM\Disk. После обновления эта информация сохраняется в других местах, специфичных для Windows, и система больше не ссылается на раздел Disk.

Диспетчер монтирования

Диспетчер монтирования, драйвер устройства Mountmgr.sys, назначает буквы томам динамических и базовых дисков, созданных после установки Windows, а также устройствам CD-ROM, приводам гибких дисков и съемным устройствам. Эта операционная система хранит все буквы дисков, назначенные томам, в разделе реестра HKLM\SYSTEM\MountedDevices. Заглянув в этот раздел, выувидите параметры с именами вида \??\Volume{X} (где X — GUID) и \DosDevices\C:. Такие параметры есть у каждого тома, но не всем томам назначены буквы дисков. Пример раздела реестра MountedDevices диспетчера монтирования показан на рис. 10–14. Заметьте, что этот раздел, как и раздел Disk в Windows NT 4, не входит в набор параметров управления и в связи с этим не восстанавливается при загрузке последней удачной конфигурации (см. главу 4).

Данные, которые хранятся в виде параметров реестра для букв и имен томов базовых дисков, представляют собой сигнатуру диска в стиле Windows NT 4 и начальное смещение от первого раздела, сопоставленного с томом. Аналогичные данные для томов динамических дисков включают внутренний GUID тома, используемый DMIO. Когда диспетчер монтирования инициализируется при загрузке системы, он регистрируется в подсистеме поддержки Plug and Play, что позволяет ему в дальнейшем получать уведомления о создании томов драйвером FtDisk или DMIO. Получив такое уведомление, диспетчер монтирования определяет GUID или сигнатуру диска нового тома и использует GUID тома или сигнатуру его диска как критерий для поиска в своей базе данных, отражающей содержимое раздела реестра MountedDevices. Если поиск заканчивается неудачей, диспетчер монтирования запрашивает у FtDisk или DMIO (смотря кто из них создал том) предлагаемую букву для идентификации тома и сохраняет ее в своей базе данных. FtDisk не дает никаких предложений, a DMIO проверяет возможные назначения в элементе тома базы данных.

Рис. 10–14. Смонтированные устройства, перечисленные в разделе реестра, принадлежащем диспетчеру монтирования

Если диспетчер монтирования не получает никаких предложений, он берет первую свободную букву, назначает ее тому, создает для нее символьную ссылку — например, \Global??\D: в Windows XP и Windows Server 2003 или \??\D: в Windows 2000 — и обновляет раздел реестра MountedDevices. Когда свободных букв нет, буква не назначается, но создается символьная ссылка \Global??\Volume{X}, определяющая GUID нового тома в том случае, если у него еще нет GUID. Этот GUID отличается от GUID томов, используемых DMIO.

Точки монтирования

Точки монтирования (mount points) позволяют связывать тома через каталоги NTFS, делая эти тома доступными без назначения букв дисков. Например, NTFS-каталог C: \Projects может монтировать другой том (NTFS или FAT), содержащий каталоги и файлы ваших проектов. Если в томе ваших проектов есть файл с именем \CurrentProject\Description.txt, то после монтирования путь к нему выглядит как C: \Projects\CurrentProject\Description.txt. Точки монтирования стали возможны благодаря технологии точек повторного разбора (reparse point technology), о которой мы подробно поговорим в главе 12.

Точка повторного разбора — это блок произвольных данных с неким фиксированным заголовком, который Windows сопоставляет с файлом или каталогом NTFS. Приложение или система определяет формат и поведение точки повторного разбора, в том числе значение уникального тэга, который идентифицирует точку повторного разбора, принадлежащую приложению или системе, и указывает размер (до 16 Кб) и смысл данных этой точки. Уникальные тэги хранятся в фиксированном сегменте точек повторного разбора. Любое приложение, реализующее точку повторного разбора, должно предоставлять драйвер фильтра файловой системы, который наблюдает за кодами возврата файловых операций, связанных с повторным разбором и выполняемых на томах NTFS, и предпринимает действия, соответствующие этим кодам. NTFS возвращает код статуса повторного разбора всякий раз, когда обрабатывает файловую операцию применительно к файлу или каталогу, с которым сопоставлена точка повторного разбора.

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

Пример приложения, поддерживающего точки повторного разбора, — система Hierarchical Storage Management (HSM) вроде службы Windows Remote Storage Service (RSS), которая включена в Windows 2000 Server и Windows Server 2003; она использует такие точки для обозначения файлов, перемещаемых администратором в хранилище на ленточных накопителях. Когда пользователь пытается обратиться к автономному файлу, драйвер фильтра HSM обнаруживает код статуса повторного разбора, возвращаемый NTFS, вызывает сервисы пользовательского режима, чтобы получить автономный файл из хранилища, удаляет из файла точку повторного разбора и инициирует повторную попытку выполнения файловой операции. Точно так же точки повторного разбора используются драйвером фильтра RSS (Rsfilter.sys).

Если файл или каталог, для которого диспетчер ввода-вывода получает от NTFS код статуса повторного разбора, не сопоставлен с одной из предопределенных в Windows точек повторного разбора, значит, его точка не обрабатывается ни одним драйвером фильтра. Тогда диспетчер ввода-вывода сообщает диспетчеру объектов об ошибке, которая передается приложению, обратившемуся к этому файлу или каталогу, в виде «file cannot be accessed by the system» («файл недоступен системе»).

Точки монтирования — это точки повторного разбора, в которых имя тома (\Global??\Volume{X}) хранится как данные повторного разбора. Назначая или удаляя пути для томов в оснастке Disk Management, вы создаете точки монтирования. Создавать и просматривать точки монтирования можно и с помощью встроенной утилиты командной строки Mountvol.exe (\Windows\System32\Mountvol.exe).

Диспетчер монтирования поддерживает на каждом томе NTFS удаленную базу данных, в которой регистрирует все точки монтирования, определенные для тома. Файл этой базы данных, $MountMgrRemoteDatabase, размещается в корневом каталоге NTFS. При перемещении диска между системами и в средах с двух вариантной загрузкой (различных систем Windows) перемещаются и точки монтирования — благодаря наличию удаленной базы данных диспетчера монтирования. NTFS отслеживает точки монтирования в файле метаданных \lExtend\IReparse (ни один из файлов метаданных NTFS не доступен приложениям). Поскольку NTFS хранит информацию о точках монтирования в файле метаданных, при соответствующем запросе Windows-приложения Windows может легко перечислить точки монтирования, определенные для тома.

ЭКСПЕРИМЕНТ: рекурсивные точки монтирования

Этот эксперимент с использованием утилиты Filemon {wwwsysinter nals.com) демонстрирует любопытное поведение системы, вызываемое рекурсивной точкой монтирования. Рекурсивной называется точка монтирования, связанная с тем томом, где она находится. Рекурсивное перечисление каталогов, выполняемое на рекурсивной точке монтирования, позволяет наглядно увидеть, как NTFS обрабатывает точки монтирования.

Для создания и просмотра точки монтирования проделайте следующее.

1. Откройте окно командной строки или Windows Explorer и создайте на NTFS-диске каталог с именем \Recurse.

2. B оснастке Disk Management (Управление дисками) консоли MMC щелкните том правой кнопкой мыши и выберите из контекстного меню команду Change Drive Letter And Path (Изменить букву диска или путь к диску).

3. B появившемся диалоговом окне введите путь к созданному вами каталогу (например, I: \Recurse).

4. Запустите Filemon. B меню Drives оставьте галочку только для тома, на котором создана точка монтирования.

Теперь вы готовы к трассировке рекурсивной точки монтирования. Откройте окно командной строки и введите dir /s I: \Recurse. Следите за ссылками на Recurse, регистрируемыми Filemon при трассировке файловых операций. Вы заметите, что сначала идет обращение к I: \Re-curse, затем к I: \Recurse\Recurse и т. д.

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

Filemon показывает запрос на открытие файла или каталога как IRP_ MJ_CREATE, запрос на закрытие файла или каталога — как IRP_MJ_CLOSE, а запрос сведений о каталогах — как IRP_MJ_DIRECTORY CONTROL, выполняемый с помощью функции FileBothDirectoryInfo (см. колонку Other).

Чтобы предотвратить переполнение буферов и вхождение в бесконечный цикл, командный процессор и Windows Explorer останавливают рекурсию по достижении 32-го уровня вложенности или при превышении длины пути в 256 символов — смотря что произойдет быстрее.

Монтирование томов

Тот факт, что Windows присваивает тому букву диска, еще не означает, что этот том содержит данные, организованные в формате файловой системы, известной Windows. Процесс распознавания тома заключается в том, что какая-либо файловая система объявляет раздел своим; первый раз этот процесс происходит при обращении ядра, драйвера устройства или приложения к какому-либо файлу или каталогу в данном томе. После того как драйвер файловой системы уведомляет о взятии на себя ответственности за управление разделом, диспетчер ввода-вывода направляет все адресованные этому тому запросы данному драйверу. Операции монтирования в Windows проходят в три этапа: регистрация драйвера файловой системы, обновление блоков параметров тома (volume parameter blocks, VPB) и запросы на монтирование.

ПРИМЕЧАНИЕ B Windows Server 2003 Enterprise и Datacenter Edition автоматическое монтирование отключено, чтобы не допустить агрессивного монтирования томов, подключенных к сети устройств хранения данных (System Area Network, SAN). Для включения или отключения автоматического монтирования можно использовать утилиту командной строки Diskpart, поставляемую с Windows Server 2003, а для монтирования томов вручную — утилиту Mountvol, также поставляемую с этой системой.

Процесс монтирования курирует диспетчер ввода-вывода, которому известны доступные драйверы файловых систем, поскольку они регистрируются у него при инициализации. Для регистрации драйверов файловых систем на локальных (не сетевых) дисках предназначена функция IoRegisterFileSystem, предоставляемая диспетчером ввода-вывода. Когда драйвер файловой системы регистрируется, диспетчер ввода-вывода сохраняет ссылку на драйвер в списке, который используется при операциях монтирования.

Каждый объект «устройство» содержит структуру данных VPB, но диспетчер ввода-вывода обращает внимание только на VPB объектов томов. VPB служит для связи между объектом тома и объектом «устройство», созданным драйвером файловой системы для представления экземпляра файловой системы, смонтированной для данного тома. Если ссылка VPB на файловую систему пуста, значит, том не смонтирован ни одной файловой системой. Диспетчер ввода-вывода проверяет VPB объекта тома всякий раз, когда выполняется API-функция открытия файла или каталога на этом объекте «устройство».

Например, если диспетчер монтирования назначает второму тому системы букву D, он создает символьную ссылку \Global??\D:, представляющую объект \Device\HarddiskVolume2. Windows-приложение, пытающееся открыть файл \Temp\Test.txt на диске D:, указывает имя D: \Temp\Test.txt, которое подсистема Windows преобразует в \Global??\D: \Temp\Test.txt перед вызовом NtCreateFile — процедуры ядра, отвечающей за открытие файла. NtCreateFile использует диспетчер объектов для разбора имени, и диспетчер объектов обнаруживает объект «устройство» \Device\HarddiskVolume2 с еще не разрешенным путем \Temp\Test.txt. Ha этом этапе диспетчер ввода-вывода проверяет, есть ли в VPB объекта \Device\HarddiskVolume2 ссылка на файловую систему. Если нет, диспетчер ввода-вывода выдает зарегистрированному драйверу файловой системы запрос на монтирование, чтобы выяснить, распознает ли он формат монтируемого тома как формат своей файловой системы.

ЭКСПЕРИМЕНТ: просмотр VPB

Увидеть содержимое VPB позволяет команда !vpb отладчика ядра. Поскольку на VPB указывает объект «устройство» тома, сначала нужно найти этот объект. Для этого создайте дамп объекта «драйвер» диспетчера томов, найдите объект «устройство», представляющий том, просмотрите его содержимое и вы обнаружите поле VPB.

Если в системе есть динамический диск, используйте команду !drvobj применительно к драйверу DMIO, а если нет — применительно к драйверу FtDisk. Вот пример:

Команда !drvobj перечисляет адреса объектов «устройство», принадлежащих драйверу. B этом примере таких объектов — семь. Один из них представляет программный интерфейс драйвера устройства, остальные — объекты томов. Поскольку объекты показываются в порядке, обратном порядку их создания, а первым создается объект «устройство» интерфейса драйвера устройства, то первый перечисленный объект «устройство» является объектом тома. Теперь введите команду !devobj отладчика ядра, указав в качестве параметра адрес объекта тома.

Команда !devobj показывает поле VPB объекта тома. (Данному объекту «устройство» присвоено имя HarddiskVolume6.) Теперь можно выполнить команду !vpb:

B итоге мы выяснили, что объект тома смонтирован драйвером файловой системы, который присвоил ему имя BACKUP. VPB-поле RealDevice указывает обратно на объект тома, а поле DeviceObject указывает на объект «устройство» смонтированной файловой системы.

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

Если драйвер файловой системы подтверждает распознавание, диспетчер ввода-вывода заполняет VPB и передает запрос на открытие с оставшейся частью пути (т. е. \Temp\Test.txt) драйверу файловой системы. Последний выполняет запрос, интерпретируя данные в соответствии с форматом своей файловой системы. После того как поля VPB объекта «устройство» тома заполнены нужной информацией, диспетчер ввода-вывода передает все последующие запросы, адресованные данному тому, драйверу смонтированной файловой системы. Если ни один драйвер файловой системы не объявляет этот том своим, владельцем становится Raw — встроенный в Ntoskrnl.exe драйвер файловой системы, который сообщает о неудаче в ответ на любые попытки открыть файл в данном разделе. Рис. 10–15 иллюстрирует упрощенную схему потока ввода-вывода, направляемого на смонтированный том (здесь не показано взаимодействие драйвера файловой системы с диспетчерами кэша и памяти).

Вместо того чтобы загружать все драйверы файловых систем независимо от наличия соответствующих томов, Windows пытается свести к минимуму нагрузку на память, используя для предварительного распознавания файловой системы суррогатный драйвер File System Recognizer (Windows \System32\ Drivers\Fs_rec.sys). Этот драйвер знает о формате каждой файловой системы, поддерживаемой Windows, ровно столько, чтобы суметь проанализировать загрузочную запись и определить, можно ли ее сопоставить с какой-нибудь файловой системой Windows. При загрузке системы File System Recognizer регистрируется как драйвер файловой системы, а при вызове диспетчером ввода-вывода в процессе монтирования файловой системы для нового тома он загружает драйвер соответствующей файловой системы, если такой драйвер еще не загружен. После этого File System Recognizer перенаправляет IRP монтирования драйверу и позволяет ему захватить том во владение.

Кроме загрузочного тома, чей драйвер монтируется при инициализации ядра, драйверы файловых систем монтируют большинство томов в момент запуска Chkdsk для проверки целостности файловой системы на этапе загрузки системы. Загрузочная версия Chkdsk является встроенным приложением (в отличие от Windows-приложений) и называется Autochk.exe (\Windows \System32\Autochk.exe). Диспетчер сеансов (\Windows\System32 \Smss.exe) запускает ее, поскольку она указана в параметре HKLM\SYSTEM\Current-ControlSet\Control\Session Manager\BootExecute. Chkdsk перебирает все назначенные буквы диска, чтобы выяснить, требует ли соответствующий том проверки целостности.

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

Операции ввода-вывода на томах

Драйверы файловых систем управляют хранящимися в томах данными, но требуют поддержки диспетчера томов для взаимодействия с драйверами устройств внешней памяти при передаче данных. Драйверы файловых систем получают ссылки на объекты томов в процессе монтирования и посылают через них запросы диспетчеру томов. Приложения — если им нужно напрямую обращаться к данным тома — тоже могут посылать запросы диспетчеру томов, обходя драйвер файловой системы. K числу таких приложений относятся, например, программы восстановления удаленных файлов и утилита DiskProbe из ресурсов Windows.

Когда драйвер файловой системы или приложение посылает объекту «устройство», представляющему том, запрос ввода-вывода, диспетчер ввода-вывода перенаправляет этот запрос (поступающий в виде IRP) диспетчеру томов, создавшему целевой объект «устройство». Таким образом, если приложению нужно считать загрузочный сектор, например, второго простого тома в системе, оно открывает объект \Device\HarddiskVolume2 и посылает ему запрос на чтение 512 байтов по нулевому смещению на устройстве. Диспетчер ввода-вывода передает запрос приложения в виде IRP диспетчеру томов, владеющему данным объектом «устройство», и уведомляет его, что IRP адресован устройству HarddiskVolume2.

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

Роль диспетчера томов в обработке запросов к составным томам помогут прояснить следующие примеры. Если чередующийся том состоит из двух разделов (1 и 2), представленных объектом \Device\HarddiskDmVolumes\ PhysicalDmVolumes\BlockVolume3 (рис. 10–16), и администратор назначил чередующейся области букву диска D:, то диспетчер ввода-вывода определяет ссылку \Global??\D:, указывающую на \Device\HarddiskDmVolumes\ComputerNameDg0\Volume3, где ComputerName — имя компьютера. Вспомните, что эта ссылка также является символьной и указывает на соответствующий объект тома в каталоге PhysicalDmVolumes (в данном случае — на BlockVolu-me3). Объект «устройство», принадлежащий DMIO, перехватывает дисковый ввод-вывод файловой системы на \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3, и драйвер DMIO корректирует параметры запроса перед тем, как передать его драйверу класса дисков. B результате изменений, внесенных DMIO, запрос настраивается так, чтобы он ссылался на нужное смещение, относительное началу целевой чередующейся области раздела 1 или 2. Если ввод-вывод затрагивает оба раздела тома, DMIO должен выдать два дополнительных запроса ввода-вывода — по одному к каждому диску.

B случае записи на зеркальный том DMIO делит каждый запрос так, что операция записи выполняется над каждой половиной зеркального тома. A при запросе на чтение с зеркального тома DMIO использует одну из половин зеркального тома и обращается к другой половине, только если первая попытка чтения заканчивается неудачно.

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

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

B Windows Server 2003 введена служба виртуального диска (Virtual Disk Service, VDS) (\Windows\System32\Vds.exe), которая предоставляет системным администраторам унифицированный высокоуровневый интерфейс внешней памяти; благодаря этому устройствами внешней памяти от разных поставщиков можно управлять через одни и те же пользовательские интерфейсы (UI). Схема VDS представлена на рис. 10–17. VDS экспортирует API, основанный на COM и позволяющий приложениям и сценариям создавать и форматировать диски, а также управлять аппаратными RAID-адаптерами. Скажем, утилита может задействовать VDS API для запроса списка физических дисков, сопоставленных с номером логического блока RAID (logical unit number, LUN). Windows-средства управления дисками, включая оснастку Disk Management консоли MMC, Diskpart и Diskraid (поставляется с Windows Server 2003 Deployment Kit), тоже используют VDS API.

VDS предоставляет два интерфейса: один — для провайдеров программного уровня, другой — для провайдеров аппаратного уровня.

• Провайдеры программного уровня (software providers) реализуют интерфейсы к таким высокоуровневым абстракциям устройств внешней памяти, как диски, разделы дисков и тома. Примеры операций, поддерживаемых этими интерфейсами, — расширение и удаление томов, включение и отключение зеркалирования, форматирование томов и присвоение им букв дисков. VDS ищет зарегистрированные программные провайдеры в HKLM\System\CurrentControlSet\Services\Vds\SoftwareProviders. Windows Server 2003 включает VDS Dynamic Disk Provider (\Windows\System32\ Vdsdyndr.dll), применяемый в качестве интерфейса для динамических дисков, и VDS Basic Provider (\Windows\System32\Vdsbas.dll), используемый в качестве интерфейса для базовых дисков.

• Провайдеры аппаратного уровня (hardware providers) реализуются изготовителями оборудования в виде DLL, которые регистрируются в разделе реестра HKLM\System\CurrentControlSet\Services\Vds\HardwareProvi-ders и которые транслируют аппаратно-независимые VDS-команды в команды, специфичные для конкретного оборудования. Провайдер аппаратного уровня позволяет управлять подсистемой внешней памяти, например аппаратным RAID-массивом или платами адаптеров/контроллеров, и поддерживает такие операции, как создание, расширение, удаление, маскирование и отмена маскирования LUN.

Когда приложение инициирует соединение с VDS API и служба VDS еще не запущена, процесс Svchost — хост службы RPC запускает процесс загрузчика VDS (\Windows\System32\Vdsldr.exe), а тот — процесс службы VDS, после чего завершается. После закрытия последнего соединения с VDS API завершается и процесс службы VDS.

Служба теневого копирования тома

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

B связи с этим в Windows XP появилась служба теневого копирования томов (Volume Shadow Copy Service) (\Windows\System32\Vssvc.exe), которая позволяет встроенной утилите резервного копирования записывать согласованные представления всех файлов, в том числе открытых. Эта служба выступает в роли командного центра расширяемого механизма резервного копирования, давая возможность независимым поставщикам программного обеспечения (independent software vendors, ISV) подключать свои провайдеры и модули записи («writers»). Модуль записи — это программный компонент, позволяющий приложениям с поддержкой теневого копирования томов принимать уведомления о замораживании и размораживании операций записи, чтобы они могли создавать внутренне согласованные резервные копии своих файлов данных. A провайдеры позволяют ISV интегрировать уникальные схемы работы с внешней памятью со службой теневого копирования томов. Например, приложение, использующее устройства внешней памяти с зерка-лированием, могло бы определять теневую копию как замороженную половину зеркалированного тома. Взаимосвязи между службой теневого копирования томов, модулями записи и провайдерами показаны на рис. 10–18.

Рис. 10–18. Служба теневого копирования томов, модули записи и провайдеры

Microsoft Shadow Copy Provider (\Windows\System32\Drivers\Volsnap.sys) — это провайдер, поставляемый с Windows для поддержки программных снимков томов. Он представляет собой драйвер фильтра внешней памяти, размещаемый между драйверами файловых систем и драйверами томов (они оперируют с наборами секторов на жестком диске, представляющими логические диски), и поэтому видит любые запросы на ввод-вывод, адресованные дисковому тому. Утилита резервного копирования, приступая к копированию, указывает драйверу Microsoft Shadow Copy Provider создать теневые копии всех томов, на которых содержатся копируемые файлы и каталоги. Драйвер замораживает все операции ввода-вывода на этих томах и для каждого из них создает теневую копию. Если, например, том в пространстве имен диспетчера объектов имеет имя \Device\HarddiskVolumeO, то теневой том получает имя в виде \Device\HarddiskVolumeShadowCopy7V, где N — уникальный идентификатор.

ЭКСПЕРИМЕНТ: просмотр объектов «устройство», принадлежащих драйверу Microsoft Shadow Copy Provider

Чтобы просмотреть такие объекты, связанные с каждым томом, в Windows XP или Windows Server 2003, используйте отладчик ядра. B любой системе есть хотя бы один том, и следующая команда выводит информацию об объекте «устройство» для первого тома в системе:

Поле AttachedDevice в выводе команды !devobj сообщает адрес объекта «устройство» и имя владеющего им драйвера, который подключен к этому объекту (фильтрует его). Каждый объект «устройства» для тома должен принадлежать драйверу Volsnap, как в показанном примере.

Вместо того чтобы открывать копируемые файлы на исходном томе, утилита резервного копирования открывает их на теневом. Последний отражает представление тома, привязанное к определенной временной точке (point-in-time view of a volume). Поэтому, когда драйвер теневого копирования томов обнаруживает попытку записи на исходный том, он считывает копию подлежащих перезаписи секторов в раздел памяти, поддерживаемый страничным файлом (paging file-backed memory section) и сопоставленный с соответствующим теневым томом. Обращения для чтения к модифицируемым секторам теневого тома драйвер обслуживает через упомянутый выше раздел памяти, а обращения для чтения к немодифицированным секторам — считыванием данных с исходного тома. Поскольку утилита резервного копирования не сохраняет страничный файл и системный каталог \System Volume Information (вместе со всеми подкаталогами и файлами), драйвер снимков, используя API-функции дефрагментации, определяет местонахождение этих файлов и каталогов и не регистрирует вносимые в них изменения. Опираясь на данный механизм, утилита резервного копирования в Windows XP и Windows Server 2003 решает все проблемы копирования, связанные с открытыми файлами.

Рис. 10–19 иллюстрирует, как ведут себя приложение, обращающееся к тому, и утилита резервного копирования, обращающаяся к теневой копии этого тома. Когда приложение пишет в сектор по истечении времени снятия снимка, драйвер Volsnap создает резервную копию, как на иллюстрации, где он копирует секторы a, b и с для тома C:. Аналогично, когда приложение считывает сектор с, Volsnap направляет операцию чтения тому C:, а когда утилита резервного копирования считывает тот же сектор, Volsnap получает содержимое этого сектора из снимка. Если операция чтения требует обращения к немодифицированному сектору, например к d, то Volsnap направляет ее исходному тому.

ЭКСПЕРИМЕНТ: просмотр объектов «устройство» теневых томов

Вы можете убедиться в наличии таких объектов в пространстве имен диспетчера объектов, запустив Windows-утилиту резервного копирования [в меню Start (Пуск) откройте Accessories (Стандартные) и System Tools (Служебные)] и выбрав достаточный объем данных для резервного копирования, чтобы успеть запустить Winobj и просмотреть объекты в подкаталоге \Device.

Драйверы файловых систем должны корректно обрабатывать два запроса на управление вводом-выводом (IOCTL), связанные с теневым копированием томов: IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES и IOCTL_VOLSNAP_RELEASE_WRITES. Смысл этих запросов не требует объяснений — он понятен из их имен. API копирования теневых томов позволяет посылать IOCTL-запросы логическим дискам, для которых создаются снимки, с тем чтобы все операции записи, инициированные перед получением снимка, успели завершиться до создания теневой копии и чтобы файловые данные, записываемые из теневой копии, были согласованы по времени.

Теневые копии для общих папок

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

B окне свойств для тома в Windows Server 2003 есть вкладка Shadow Copies (Теневые копии), на которой администратор может разрешить создание снимков томов по расписанию, как показано на следующей иллюстрации. Администраторы также могут ограничить пространство, выделяемое под снимки, чтобы система автоматически удаляла самые старые снимки.

B клиентских системах, где нужна функциональность Shadow Copies for Shared Folders, следует установить расширение Explorer — Previous Versions Client — которое поставляется c Windows Server 2003 в каталоге \Windows\System32\Clients\Twclient и которое также можно скачать с сайта Microsoft (это расширение включено в Windows XP Service Pack 2 и выше). Когда клиентская Windows-система с установленным расширением подключается к общей папке на томе, для которого имеются снимки, в окне свойств папок и файлов, находящихся в этой общей папке, появляется вкладка Previous Versions. Ha этой вкладке перечисляются снимки, имеющиеся на сервере, и пользователь может просмотреть соответствующие версии файла или папки.

Резюме

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

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

Вспомните из главы 7, что при усечении рабочего набора или замене страниц диспетчер памяти может переместить измененные страницы из рабочего набора в список простаивающих или модифицированных страниц — в зависимости от того, куда должны быть записаны данные, содержащиеся на такой странице, перед ее повторным использованием — в страничный файл или в какой-то другой. Если бы у диспетчера памяти не было таких списков, то всякий раз, когда какой-нибудь процесс обращался бы к данным, ранее удаленным из его рабочего набора, диспетчеру памяти приходилось бы считывать их с диска. A так диспетчер памяти может просто вернуть нужную страницу в рабочий набор процесса (если она, конечно, присутствует в одном из этих списков). To есть списки служат кэшами данных из страничного файла, исполняемых образов или файлов данных. Значит, общий объем файловых данных, кэшируемых в системе, складывается не только из размера системного рабочего набора, но и из размеров списков простаивающих и модифицированных страниц.

Вот пример, иллюстрирующий, как диспетчер кэша способен привести к кэшированию в физической памяти гораздо большего объема файловых данных, чем может содержаться в системном рабочем наборе. Рассмотрим систему, выступающую в роли выделенного файл-сервера. B этой системе имеется 8 Гб физической памяти, и виртуальный размер кэша составляет 960 Мб (максимальный размер в х86-системах). Таким образом, предельный размер файловых данных, которые можно напрямую спроецировать в виртуальную память кэша, составляет 960 Мб. Клиентское приложение обращается к файловым данным на сервере через сеть. Драйвер файл-сервера (\Windows\System32\Drivers\Srv.sys) (см. главу 12) использует интерфейсы диспетчера кэша для чтения и записи файловых данных в интересах клиента. Если клиенты считывают несколько тысяч файлов, каждый размером по 1 Мб, диспетчеру кэша придется повторно использовать представления при проецировании 961-го файла. При последующих операциях чтения он будет отменять проецирование представлений для старых файлов и заново проецировать их для новых. Когда диспетчер кэша отменяет проецирование какого-либо представления, диспетчер памяти не отбрасывает файловые данные в рабочем наборе кэша, соответствующие этому представлению, а перемещает их в список простаивающих страниц. B отсутствие запросов на выделение физической памяти под любые другие задачи список простаивающих страниц может занимать почти всю физическую память за вычетом системного рабочего набора. Иначе говоря, практически все 8 Гб физической памяти сервера будут задействованы для кэширования файловых данных, как показано на рис. 11-6.

Рис. 11 -6. Пример использования почти всей физической памяти под файловый кэш

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

Для более точного отображения полного объема файловых данных, кэшируемых в системе, диспетчер задач и Process Explorer предоставляют параметр System Cache (Системный кэш), отражающий суммарный размер системного рабочего набора и списков простаивающих и модифицированных страниц. Пример для Process Explorer представлен на рис. 11-7.

Структуры данных кэша

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

• Каждый 256-килобайтный слот системного кэша описывается VACB.

• У каждого отдельно открытого кэшируемого файла есть закрытая карта кэша с информацией, применяемой для контроля опережающего чтения.

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

Эти структуры и их взаимосвязи описываются в следующих разделах.

Общесистемные структуры данных кэша

Диспетчер кэша отслеживает состояние спроецированных на системный кэш представлений с помощью массива структур данных, называемых блоками управления виртуальными адресами (virtual address control blocks, VACB). При инициализации системы диспетчер кэша выделяет часть пула неподкачиваемой памяти под VACB, необходимые для описания системного кэша. Адрес массива VACB запоминается в переменной CcVacbs. Каждый VACB описывает одно 256-килобайтное представление в системном кэше (рис. 11-8). Структура VACB показана на рис. 11-9.

Как видно на рис. 11-9, в первом поле VACB содержится виртуальный адрес данных системного кэша. Второе поле является указателем на общую (совместно используемую) структуру карты кэша, которая идентифицирует кэшируемый файл. Третье поле определяет смещение начала представления (внутри файла). Наконец, VACB содержит счетчик ссылок на представление, т. е. число активных операций чтения или записи над данным представлением. При выполнении операции ввода-вывода над файлом счетчик ссылок VACB увеличивается на 1, а по окончании такой операции уменьшается на 1. Когда счетчик ссылок не равен 0, VACB считается активным. B случае обращения к метаданным файловой системы счетчик активных операций отражает число драйверов файловых систем, которые владеют заблокированными в памяти страницами данного представления.

Структуры данных кэша, индивидуальные для каждого файла

Каждому открытому описателю файла соответствует объект «файл» (см. главу 9). Если файл кэшируется, его объект «файл» указывает на структуру закрытой карты кэша (private cache map), которая содержитдва адреса, по которым в последний раз происходило чтение данных. Кроме того, все закрытые карты кэша для открытых экземпляров файла связаны друг с другом.

У каждого кэшируемого файла (в противоположность объекту «файл») есть структура общей карты кэша (shared cache map), которая описывает состояние кэшируемого файла, в том числе его размер и (из соображений безопасности) длину его действительных данных. (O назначении поля длины действительных данных файла см. раздел «Кэширование с обратной записью и отложенная запись» далее в этой главе). Общая карта кэша также указывает на объект-раздел (поддерживаемый диспетчером памяти и описывающий проекцию файла на виртуальную память), список закрытых карт памяти, сопоставленных с этим файлом, и все VACB, описывающие представления файлов, проецируемые в данный момент на системный кэш. Взаимосвязи между этими структурами данных показаны на рис. 11–10.

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

1. Находится ли файл в кэше?

2. Если да, то какие VACB (если таковые есть) ссылаются на запрошенный адрес?

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

Для учета представлений данного файла, проецируемых на системный кэш, диспетчер кэша поддерживает массив указателей на VACB — массив индексов VACB (VACB index array). Первый элемент массива индексов VACB ссылается на первые 256 Кб файла, второй — на следующие 256 Кб и т. д.

Схема на рис. 11–11 иллюстрирует четыре раздела из трех файлов, проецируемых в данный момент на системный кэш.

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

Рис. 11–10. Структуры данных кэша, индивидуальные для файлов

Для оптимизации своего размера общая карта кэша содержит массив индексов VACB из 4 элементов. Поскольку каждый VACB описывает 256 Кб, элементы этого компактного массива индексов фиксированного размера могут указывать на элементы массива VACB, которые в совокупности способны описывать файл размером до 1 Мб. Если размер файла превышает 1 Мб, из неподкачиваемого пула выделяется память под отдельный массив индексов VACB; его размер определяется делением размера файла на 256 Кб с последующим округлением результата до ближайшего большего целого значения. После этого общая карта кэша указывает на данную структуру.

Рис. 11–11. Массивы индексов VACB

Если длина файла превышает 32 Мб, то для еще большей оптимизации массив индексов VACB, созданный в пуле неподкачиваемой памяти, становится разреженным многоуровневым массивом индексов (sparse multilevel index array), в котором каждый массив индексов состоит из 128 элементов. Число уровней, необходимых для файла, вычисляется по формуле:

(Разрядность значения, отражающего длину файла — 18) / 7

Полученное значение надо округлить до ближайшего большего целого. Число 18 в уравнении обусловлено тем, что VACB представляет 256 Кб, а 256 Кб — это 2¹⁸. Наконец, число 7 присутствует в уравнении потому, что каждый уровень массива состоит из 128 элементов, а 128 — это 2⁷. Следовательно, файл максимальной длины, которая может быть описана как 2⁶³ (максимальный размер, поддерживаемый диспетчером кэша), потребует всего 7 уровней. Массив является разреженным, так какдиспетчер кэша создает ветви лишь для активных представлений на самом низком уровне массива индексов. Ha рис. 11–12 показан пример многоуровневого массива VACB для разреженного файла, размер которого требует для описания 3 уровня.

Такая схема нужна для эффективной обработки разреженных файлов, которые могут достигать очень больших размеров и в которых лишь малая часть может быть занята действительными данными; поэтому в массиве выделяется ровно столько места, сколько нужно для проецируемых в данный момент представлений файла. Например, разреженный файл размером 32 Гб, у которого только 256 Кб проецируются на виртуальное адресное пространство кэша, потребует массив VACB с тремя массивами индексов, поскольку лишь одна ветвь массива имеет проекцию, а для файла длиной 32 Гб (2³⁵ байтов) нужен трехуровневый массив. Если бы диспетчер кэша не оптимизировал многоуровневые массивы VACB, для этого файла пришлось бы создать массив VACB со 128 000 элементов, что эквивалентно 1000 массивам индексов.

ЭКСПЕРИМЕНТ: просмотр общей и закрытых карт кэша

Команда dt отладчика ядра позволяет увидеть определения структур данных общей и закрытой карт кэша в работающей системе. Во-первых, выполните команду !filecache и найдите запись в выводе VACB с именем известного вам файла. B нашем примере таковым будет справочный файл из Debugging Tools for Windows:

8653c828 120 160 0 0 debugger.chm

Первый адрес указывает местонахождение структуры данных области управления (control area), с помощью которой диспетчер памяти отслеживает диапазон адресов. (Более подробные сведения см. в главе 7.) B области управления хранится указатель на объект «файл», coответствующий представлению в кэше. Объект «файл» идентифицирует экземпляр открытого файла — в данном случае справочного файла из Debugging Tools for Windows. Теперь, чтобы увидеть структуру области управления, введите следующую команду с адресом идентифицированного вами элемента в этой области:

Потом изучите объект «файл», на который ссылается область управления:

Интерфейсы файловых систем

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

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

• копирование (copy method) — пользовательские данные копируются между буферами кэша в системном пространстве и буфером процесса в пользовательском пространстве;

• проецирование и фиксация (mapping and pinning method) — данные считываются и записываются прямо в буферы кэша по виртуальным адресам;

• обращение к физической памяти (phisycal memory access method) — данные считываются и записываются прямо в буферы кэша по физическим адресам.

Чтобы избежать бесконечного цикла при обработке диспетчером памяти ошибки страницы, драйверы файловых систем должны поддерживать два варианта чтения файлов — с кэшированием и без. B таких случаях диспетчер памяти вызывает файловую систему для получения данных из файла (через драйвер устройства) и запрашивает операцию чтения без кэширования, устанавливая в IRP флаг «no cache».

Рис. 11–13 иллюстрирует типичное взаимодействие между диспетчером кэша, диспетчером памяти и драйверами файловой системы в ответ на пользовательские операции файлового ввода-вывода (чтения или записи). Диспетчер кэша вызывается файловой системой через интерфейсы копирования (функции CcCopyRead и CcCopyWrite). Чтобы обработать, например, операцию чтения, инициированную через CcFastCopyRead или CcCopyRead, диспетчер кэша создает представление в кэше для проецирования части запрошенного файла и считывает файловые данные в пользовательский буфер, копируя их из представления. Операция копирования генерирует ошибки страниц по мере обращения к каждой ранее недействительной странице в представлении, и в ответ диспетчер памяти инициирует ввод-вывод без кэширования, используя драйвер файловой системы для выборки данных, соответствующих части файла, спроецированной на ту страницу, которая оказалась недействительной.

Рис. 11–13. Взаимодействие файловой системы с диспетчерами кэша и памяти

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

Копирование данных в кэш и из него

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

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

Кэширование с применением интерфейсов проецирования и фиксации

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

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

Если драйверу файловой системы необходимо модифицировать страницы кэша, он вызывает сервисы диспетчера кэша, отвечающие за фиксацию модифицируемых страниц в памяти. Ha самом деле эти страницы не блокируются в памяти (как это происходит в тех случаях, когда драйвер устройства блокирует страницы для передачи данных с использованием прямого доступа к памяти). По большей части драйвер файловой системы помечает их поток метаданных как «no write», сообщая подсистеме записи модифицированных страниц диспетчера памяти (см. главу 7) не сбрасывать страницы на диск до тех пор, пока не будет явно указано иное. После отмены фиксации страниц диспетчер кэша сбрасывает на диск все измененные страницы и освобождает представление кэша, которое было занято метаданными.

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

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

Кэширование с применением прямого доступа к памяти

B дополнение к интерфейсам проецирования и фиксации, используемым при прямом обращении к кэшированным метаданным, диспетчер кэша предоставляет третий интерфейс — прямой доступ к памяти (direct memory access, DMA). Функции DMA применяются для чтения или записи страниц кэша без промежуточных буферов, например сетевой файловой системой при передаче данных по сети.

Интерфейс DMA возвращает файловой системе физические адреса кэшируемых пользовательских данных (а не виртуальные, которые возвращаются интерфейсами проецирования и фиксации), и эти адреса могут быть использованы для прямой передачи данных из физической памяти на сетевое устройство. Хотя при передаче небольших порций данных (1–2 Кб) можно пользоваться обычными интерфейсами копирования на основе буферов, при передаче больших объемов данных интерфейс DMA значительно повышает быстродействие сетевого сервера, обрабатывающего файловые запросы от удаленных систем.

Для описания ссылок на физическую память служит список дескрипторов памяти (memory descriptor list, MDL) (см. главу 7). DMA-интерфейс диспетчера кэша состоит их четырех функций (таблица 11-8).

Вы можете исследовать активность, связанную с MDL-чтением из кэша, через счетчики производительности или системные переменные, перечисленные в таблице 11-9.

Быстрый ввод-вывод

Операции чтения и записи, выполняемые над кэшируемыми файлами, по возможности обрабатываются с применением высокоскоростного механизма — быстрого eeoдa-вывода (fast I/O). Как уже говорилось в главе 9, быстрый ввод-вывод обеспечивает чтение и запись кэшируемых файлов без генерации IRR При использовании этого механизма диспетчер ввода-вывода вызывает процедуру быстрого ввода-вывода, принадлежащую драйверу файловой системы, и определяет, можно ли удовлетворить ввод-вывод непосредственно из кэша без генерации IRR

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

Быстрый ввод-вывод возможен не всегда. Например, первая операция чтения или записи требует подготовки файла к кэшированию (его проецирования на кэш и создания структур данных кэша, описанных в разделе «Структуры данных кэша» ранее в этой главе). Быстрый ввод-вывод не применяется и в том случае, если вызывающий поток указывает асинхронное чтение или запись, поскольку этот поток может быть приостановлен в ходе операций ввода-вывода, связанных с подкачкой и необходимых для копирования буферов в системный кэш (и из него), и фактически синхронного выполнения запрошенной операции асинхронного ввода-вывода. Однако даже при синхронном вводе-выводе драйвер файловой системы может решить, что обработка запрошенной операции по механизму быстрого ввода-вывода недопустима, если, например, в нужном файле заблокирован какой-то диапазон байтов (в результате вызова Windows-функции LockFile). Поскольку диспетчер кэша не знает, какие части и каких файлов блокированы, драйвер файловой системы должен проверить возможность чтения или записи запрошенных данных, а это требует генерации IRR Алгоритм принятия решений показан на рис. 11–14.

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

1. Поток выполняет операцию чтения или записи.

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

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

4. Диспетчер кэша транслирует переданное смещение в файле в виртуальный адрес данных в кэше.

5. При операциях чтения диспетчер кэша копирует данные из кэша в буфер процесса, а при операциях записи — из буфера процесса в кэш.

6. Выполняется одна из следующих операций:

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

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

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

ПРИМЕЧАНИЕ Быстрый ввод-вывод возможен не только в тех случаях, когда запрошенные данные уже находятся в физической памяти. Как видно из пп. 5 и 6 предыдущего списка, диспетчер кэша просто обращается по виртуальным адресам уже открытого файла, где он предполагает найти нужные данные. Если происходит промах кэша, диспетчер памяти динамически подгружает эти данные в физическую память.

Счетчики производительности и системные переменные, перечисленные в таблице 11–10, позволяют наблюдать за операциями быстрого ввода-вывода в системе.

Опережающее чтение и отложенная запись

Здесь вы увидите, как диспетчер кэша реализует чтение и запись файловых данных в интересах драйверов файловых систем. Учтите, что диспетчер кэша участвует в файловом вводе-выводе только при открытии файла без флага FILE_FLAG_NO_BUFFERING и последующем чтении или записи через Windows-функции ввода-вывода (например, функции ReadFile и WriteFile). Кроме того, диспетчер кэша не имеет дела с проецируемыми файлами, а также с файлами, открытыми с флагом FILE_FLAG_NO_BUFFERING.

Интеллектуальное опережающее чтение

Для реализации интеллектуального опережающего чтения (intelligent read-ahead) диспетчер кэша использует принцип пространственной локальности (spatial locality); исходя из данных, которые вызывающий процесс считывает в данный момент, диспетчер кэша пытается предсказать, какие данные тот будет считывать в следующий раз. Поскольку системный кэш опирается на использование виртуальных адресов, непрерывных для конкретного файла, их непрерывность в физической памяти не имеет значения. Реализация опережающего чтения файлов при кэшировании на основе логических блоков была бы гораздо сложнее и потребовала бы тесной координации между драйверами файловых систем и кэшем, поскольку такая система кэширования опирается на относительные позиции затребованных данных на диске, а файлы вовсе не обязательно хранятся в непрерывных областях диска. Активность, связанную с опережающим чтением, можно исследовать с помощью счетчика производительности Cache: Read Aheads/Sec (Кэш: Упреждающих чтений/сек) или системной переменной CcReadAheadIos.

Считывание следующего блока файла, к которому происходит последовательное обращение, дает очевидные преимущества. Чтобы распространить эти преимущества и на случаи произвольного (прямого) доступа к данным (в направлении вперед или назад), диспетчер кэша запоминает последние два запроса на чтение в закрытой карте кэша, сопоставленной с описателем файла, к которому обращается программа. Этот метод называется асинхронным опережающим чтением с хронологией. Диспетчер кэша пытается выявить какую-то закономерность в операциях прямого чтения вызывающей программы. Например, если вызывающая программа считывает сначала страницу 4000, затем 3000, диспетчер кэша предполагает, что в следующий раз будет затребована страница 2000, и заблаговременно считывает ее в кэш.

ПРИМЕЧАНИЕ Хотя предсказание возможно лишь на основе последовательности из трех операций чтения минимум, в закрытой карте кэша запоминаются только две из них.

Чтобы еще больше повысить эффективность опережающего чтения, Windows-функция CreateFile поддерживает флаг последовательного доступа к файлу, FILE_FLAG_SEQUENTIAL_SCAN. Если этот флаг задан, диспетчер кэша не ведет хронологию чтения для предсказаний, выполняя вместо этого последовательное опережающее чтение. Ho по мере считывания файла в рабочий набор кэша диспетчер кэша удаляет проекции неактивных представлений файла и командует диспетчеру памяти переместить страницы, принадлежавшие удаленным проекциям, в начало списка простаивающих или модифицированных страниц (если страницы изменены), чтобы впоследствии их можно было быстро использовать повторно. Он также заранее считывает двукратный объем данных (например, 128 Кб вместо 64 Кб). По мере того как вызывающий поток продолжает считывать данные, диспетчер кэша считывает дополнительные блоки данных, всегда опережая вызывающий поток на один блок, равный текущему запрошенному.

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

B случае приложений, для которых невозможно предсказать схему чтения данных, функция CreateFile предусматривает флаг FILE_FLAG_RANDOM_ ACCESS. Этот флаг запрещает диспетчеру кэша предсказание адресов следующих операций чтения и тем самым отключает опережающее чтение. Этот флаг также предотвращает агрессивное удаление диспетчером кэша проекций представлений файла по мере обращения к его (файла) данным, что минимизирует число операций проецирования/удаления проекций, выполняемых над файлом при повторном обращении приложения к тем же областям файла.

Кэширование с обратной записью и отложенная запись

Диспетчер кэша реализует кэш с обратной отложенной записью (write-back cache with lazy write). Это означает, что данные, записываемые в файлы, сначала хранятся в страницах кэша в памяти, а потом записываются на диск. Таким образом, записываемые данные в течение некоторого времени накапливаются, после чего сбрасываются на диск пакетом, что уменьшает общее число операций дискового ввода-вывода.

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

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

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

ПРИМЕЧАНИЕ Диспетчер кэша предоставляет драйверам файловой системы средства, позволяющие отслеживать, когда и сколько данных было записано в файл. После того как подсистема отложенной записи сбрасывает на диск измененные страницы, диспетчер кэша уведомляет об этом файловую систему, чтобы она обновила свое значение для длины действительных данных файла. (Диспетчер кэша и файловые системы раздельно отслеживают длину действительных данных для файла в памяти.)

Наблюдать за активностью подсистемы отложенной записи позволяют счетчики производительности или системные переменные, перечисленные в таблице 11–11.

Отключение отложенной записи для файла

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

Принудительное включение в кэше сквозной записи на диск

Поскольку некоторые приложения не терпят ни малейших задержек между записью в файл и реальным обновлением данных на диске, диспетчер кэша поддерживает кэширование со сквозной записью (write-through caching), включаемое для каждого объекта «файл» индивидуально; при этом изменения записываются на диск по мере их внесения. Чтобы включить кэширование со сквозной записью, при вызове функции CreateFile надо установить флаг FILE_FLAG_WRITE_THROUGH. B качестве альтернативы поток может явно сбрасывать на диск измененные данные вызовом Windows-функции FlushFileBuffers. Вы можете наблюдать за операциями сброса кэша в результате запросов на сквозной ввод-вывод или явных вызовов FlushFileBuffers через счетчики производительности или системные переменные, перечисленные в таблице 11–12.

Сброс проецируемых файлов

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

1. Пользователь удаляет проекцию представления.

2. Процесс сбрасывает файловые буферы.

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

ЭКСПЕРИМЕНТ: наблюдение за операциями сброса кэша

Вы можете увидеть, как диспетчер кэша проецирует представления в системный кэш и сбрасывает страницы на диск, запустив оснастку Performance (Производительность) и добавив счетчики Data Maps/sec (Отображений данных/сек) и LazyWrite Flushes/sec (Сбросов ленивой записи/сек), а затем скопировав большой файл из одного места в другое. Ha следующей иллюстрации показаны графики, относящиеся к Data Maps/sec (верхний) и к LazyWrite Flushes/sec (нижний).

Дросселирование записи

Файловая система и диспетчер кэша должны определять, повлияет ли запрос кэшированной записи на производительность системы, и исходя из этого планировать отложенные операции записи. Сначала файловая система через функцию CcCanIWrite выясняет у диспетчера кэша, можно ли записать определенное число байтов прямо сейчас без ущерба для производительности, и при необходимости блокирует запись. Далее она настраивает обратный вызов диспетчера кэша для автоматической записи данных на диск, когда запись вновь будет разрешена вызовом CcDeferWrite. Получив уведомление о предстоящей операции записи, диспетчер кэша определяет, сколько измененных страниц находится в кэше и какой объем физической памяти доступен. Если свободных физических страниц мало, диспетчер кэша немедленно блокирует поток файловой системы, выдавший запрос на запись данных в кэш. Подсистема отложенной записи сбрасывает часть измененных страниц на диск, после чего разрешает продолжить выполнение блокированного потока файловой системы. Такой механизм, называемый дросселированием записи (write throttling), предотвращает падение быстродействия системы из-за нехватки памяти при операциях записи большого объема данных, инициируемых файловой системой или сетевым сервером.

ПРИМЕЧАНИЕ Дросселирование записи оказывает глобальное влияние на систему, так как ресурс, на котором основан этот механизм, — свободная физическая память — является глобальным. И если интенсивная запись на медленное устройство вызывает дросселирование, это распространяется на операции записи и на другие устройства.

Пороговое число измененных страниц (dirty page threshold) — это количество страниц, хранимых системным кэшем в памяти, по достижении которого пробуждается поток подсистемы отложенной записи для сброса страниц на диск. Это значение вычисляется при инициализации системы и зависит от объема физической памяти и параметра реестра LargeSystemCache, как мы уже объясняли.

Алгоритм расчета порогового числа измененных страниц представлен в таблице 11–13. Результат расчета с использованием этого алгоритма игнорируется, если максимальный размер системного рабочего набора превышает 4 Мб, — а именно так зачастую и происходит. (Определение малого, среднего и большого объема системной памяти см. в главе 7.) Когда максимальный размер рабочего набора превышает 4 Мб, пороговое число измененных страниц устанавливается равным максимальному размеру системного рабочего набора за вычетом 2 Мб.

Дросселирование записи также полезно для сетевых редиректоров, передающих данные по медленным коммуникационным каналам. Вообразите, например, локальный процесс, записывающий большой объем данных в удаленную файловую систему по каналу, работающему со скоростью 9600 бод. Данные не попадут на удаленный диск, пока подсистема отложенной записи диспетчера кэша не сбросит кэш на диск. Если редиректор накапливает много измененных страниц, одновременно сбрасываемых на диск, на принимающей стороне может истечь время ожидания данных до окончания их передачи. Развитие событий по такому сценарию можно предотвратить с помощью функции диспетчера кэша CcSetDirtyPageTbresbold, позволяющей сетевым редиректорам устанавливать лимит на количество измененных страниц, которые можно накапливать без сброса на диск. Ограничивая число измененных страниц, редиректор гарантирует, что операции сброса кэша не вызовут таймаута.

ПРИМЕЧАНИЕ B Windows XP и выше сетевые редиректоры не задают пороговое значение измененных страниц, вместо этого полагаясь на системные значения по умолчанию.

ЭКСПЕРИМЕНТ: просмотр параметров дросселирования записи

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

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

Системные потоки

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

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

• экспресс-очередь (express queue) — для операций опережающего чтения;

• регулярная очередь (regular queue) — для отложенной записи измененных данных, подлежащих сбросу, обратной записи и отложенного закрытия файлов.

Чтобы отслеживать рабочие элементы, направленные рабочим потокам, диспетчер кэша создает собственный ассоциативный список (индивидуальный для каждого процессора и имеющий фиксированную длину) структур рабочих элементов, поставленных в очереди рабочих потоков (ассоциативные списки обсуждаются в главе 7). Число элементов в очереди рабочего потока определяется объемом системной памяти и для систем Windows Professional составляет 32,64 или 128 в системах с малым, средним или большим объемом памяти соответственно (для систем Windows Server с большим объемом памяти — 256).

Резюме

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