Внутреннее устройство ядра Windows Vista: Часть 3

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

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

В компоненте управления учетными записями пользователей (UAC — User Account Control), который не рассматривается в этой серии, используется несколько разных технологий, включая виртуализацию файловой системы и реестра для устаревших приложений, согласие на повышение уровня для получения доступа к административным правам и механизм Windows® Integrity Level для изоляции процессов, работающих с административными правами, от процессов с низким уровнем привилегий, работающих в рамках одной и той же учетной записи. Подробное обсуждение структуры компонента UAC появится в будущем выпуске TechNet Magazine.

В операционной системе Windows Vista™ повышение надежности системы и расширение возможностей пользователя при диагностике неполадок системы и приложений достигается посредством ряда новых компонентов и усовершенствований. Например, модуль регистрации отслеживания событий ядра для Windows (ETW) всегда находится в активном состоянии, создавая в кольцевом буфере события отслеживания для операций с файлами, реестром, прерываний и операций других видов. При возникновении неполадки новая диагностическая инфраструктура Windows (WDI) делает моментальный снимок буфера и анализирует его локально или загружает в службу технической поддержки Майкрософт для поиска и устранения неполадки.

Новый монитор производительности и надежности позволяет пользователям соотносить ошибки, например, сбои и зависания, с изменениями, внесенными в настройку системы. Мощный инструмент восстановления системы (SRT) заменяет консоль восстановления для восстановления в автономном режиме систем, не подлежащих перезагрузке.

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

Диспетчер транзакций ядра

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

Приложения, написанные для Windows Vista, при очень небольшой затрате усилий могут приобрести возможности автоматического восстановления после ошибок, используя для этого новую поддержку транзакций в NTFS и реестре, обеспечиваемую диспетчером транзакций ядра. Если приложению требуется выполнить ряд связанных изменений, оно может либо создать транзакцию координатора распределенных транзакций (DTC) и дескриптор транзакции KTM, либо напрямую создать дескриптор KTM и уставить связь между изменениями файлов и разделов реестра с транзакцией. В случае успешного завершения всех изменений приложение выполняет транзакцию, и изменения применяются, но в любой момент вплоть до этой точки приложение может выполнить откат транзакции, после чего изменения будут аннулированы.

Следующее преимущество состоит в том, что другие приложения не видят изменений, внесенных в транзакции, пока транзакция не будет завершена, а приложения, использующие DTC в Windows Vista и готовящийся к выпуску сервер Windows Server®, носящий кодовое название «Longhorn», могут координировать свои транзакции с помощью SQL Server™, сервера очереди сообщений Microsoft® (MSMQ) и других баз данных. Следовательно, служба обновления приложений, использующая транзакции KTM, никогда не оставит приложение в противоречивом состоянии. Именно поэтому как инструмент обновления Windows, так и инструмент восстановления системы используют транзакции.

Являясь основой поддержки транзакций, KTM обеспечивает диспетчерам транзакционных ресурсов, таких как NTFS и реестр, возможность координировать свои обновления в случае конкретного набора изменений, выполненных приложением. В Windows Vista файловая система NTFS использует для поддержки транзакций расширение TxF. Реестр использует аналогичное расширение с названием TxR. Эти диспетчеры ресурсов режима ядра работают совместно с KTM, координируя состояние транзакции, точно так же, как диспетчеры ресурсов пользовательского режима используют DTC для координации состояния транзакции в нескольких диспетчерах ресурсов пользовательского режима. Сторонние разработчики также могут использовать KTM для реализации своих собственных диспетчеров ресурсов.

Как TxF, так и TxR определяют новый набор интерфейсов файловой системы и реестров, аналогичных существующим, за исключением того, что в них включен параметр транзакции. Если приложению требуется создать файл в рамках транзакции, сначала используется KTM для создания транзакции, затем результирующая обработка транзакции передается интерфейсу API создания нового файла.

Как TxF, так и TxR основаны на быстро работающих функциях ведения журнала файловой системы, обеспечиваемых общей системой файлов журнала или системой CLFS (Common Log File System) (%SystemRoot%\System32\Clfs.sys), которая была введена в Windows Server 2003 R2. TxR и TxF используют CLFS для надежного хранения транзакционных изменений до завершения транзакции. Это позволяет им обеспечивать транзакционное восстановление и гарантии даже в случае сбоя в подаче питания. Кроме журнала CLFS расширение TxR создает набор связанных файлов журнала для отслеживания изменений в системном файле реестра в %Systemroot%\System32\Config\Txr, как показано на рис. 1, а также отдельные наборы файлов журналов для каждого пользовательского куста реестра. TxF хранит транзакционные данные для каждого тома в скрытом каталоге на томе с именем \$Extend\$RmMetadata.

Рис. 1 Файлы журналов, ведущихся расширением TxR для куста системного реестра

Усовершенствованная поддержка при сбоях

В случае возникновения в Windows неустранимой ошибки режима ядра — из-за ошибок в драйвере устройства, сбоев оборудования или операционной системы — выполняется попытка предотвратить повреждение данных, хранящихся на диске, посредством остановки работы системы после отображения печально известного «синего экрана» и, если имеется соответствующая настройка, записи содержимого некоторого участка или всей физической памяти в файл аварийной копии памяти. Файлы аварийной копии памяти полезны, поскольку при перезагрузке после сбоя интерактивная служба Майкрософт для анализа сбоя (OCA — Online Crash Analysis) предлагает выполнить их анализ для поиска причины сбоя. При желании их можно проанализировать самостоятельно с помощью средств Майкрософт для отладки в Windows).

Однако в предыдущих версиях Windows поддержка файлов аварийной копии памяти оставалась не активированной до момента инициализации файлов страниц памяти процессом диспетчера сеанса (%Systemroot%\System32\Smss.exe). Это означало, что любые важные ошибки, возникавшие до этого момента, приводили к отображению синего экрана, а файл с копией памяти не создавался. Поскольку основная часть инициализации драйвера устройства происходит до запуска Smss.exe, сбои на раннем этапе никогда не сопровождаются аварийными копиями памяти, что крайне затрудняет выявление причин.

В Windows Vista период времени, в течение которого не создается файл копии памяти, сокращен благодаря инициализации поддержки файла копии памяти до загрузки драйверов этапа запуска системы, сразу после инициализации всех драйверов устройств, необходимых на этапе первоначальной загрузки. Вследствие этого изменения при возникновении сбоя на раннем этапе процесса первоначальной загрузки система может сделать аварийную копию памяти, наличие которой позволяет использовать OCA для разрешения возникшей проблемы. Кроме этого, Windows Vista сохраняет данные в файле копии памяти в виде блоков по 64 КБ, в то время как в предыдущей версии Windows файлы записывались с использованием блоков по 4 КБ. В результате этого изменения большие файлы копии памяти записываются в 10 раз быстрее.

В Windows Vista усовершенствована также обработка сбоев приложений. В предыдущих версиях Windows при возникновении сбоя приложения выполнялся обработчик необработанных исключений. Обработчик запускал процесс Майкрософт для создания сообщения об ошибках приложения (AER) (%Systemroot%\System32\Dwwin.exe), отображающий диалоговое окно с указанием программы, в которой возник сбой, и запросом об отправке сообщения об ошибке в Майкрософт. Однако, если во время сбоя повреждался стек основного потока процесса, при выполнении обработчика необработанных исключений возникал сбой, приводящий к завершению процесса ядром, мгновенному исчезновению окон программы и полному отсутствию диалогового окна с сообщением.

В Windows Vista обработка ошибок перемещена из контекста обработки сбоев в новую службу создания сообщений об ошибках Windows (WER). Эта служба реализуется посредством библиотеки DLL (%Systemroot%\System32\Wersvc.dll) в рамках процесса размещения службы. При возникновении сбоя приложения по-прежнему выполняется обработчик необработанных исключений, но обработчик отправляет сообщение службе WER, и служба запускает процесс создания сообщений об отказах WER (%Systemroot%\System32\Werfault.exe) для отображения диалогового окна с сообщением об ошибке. Если стек поврежден, и возникает сбой обработчика необработанных исключений, обработчик выполняется повторно и снова возникает сбой, то, в конце концов, исчерпывая весь стек потока (вспомогательная область памяти), и в этот момент вступает в игру ядро и отправляет службе сообщение с уведомлением о сбое.

Отличие этих двух подходов видны на рис. 2 и 3, где показана взаимосвязь процессов Accvio.exe, тестовой программы, в которой возник сбой, и процессов создания сообщений об ошибках, выделенных зеленым цветом, в операционных системах Windows XP и Windows Vista. Новая архитектура обработки ошибок в Windows Vista означает, что программы больше не будут молча заканчивать работу, не предлагая Майкрософт возможности получить сообщение об ошибке, и разработчики программного обеспечения смогут усовершенствовать свои приложения.

Рис. 2б Обработка ошибок приложений в Windows XP

Рис. 2б 

Рис. 3а Обработка ошибок приложений в Windows Vista

Рис. 3б 

Теневое копирование тома

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

Эти моментальные снимки не являются, по существу, полными копиями томов. Скорее они представляют собой виды тома из некоторой предшествующей точки, содержащие оперативные данные тома, перекрытые копиями секторов тома, подвергавшихся изменениям с момента создания моментального снимка. Драйвер поставщика моментальных снимков томов (%Systemroot\%System32\Drivers\Volsnap.sys) контролирует операции, в которых участвуют тома, и, прежде чем разрешить изменение секторов, делает их резервные копии, сохраняя исходные данные в файле, связанном с моментальным снимком, в каталоге тома, содержащем системную информацию о томе.

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

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

В Windows Vista преимущества моментальных снимков томов используются также для того, чтобы объединить механизмы защиты пользовательских и системных данных и избежать сохранения избыточного объема данных резервного копирования. Если установка приложения или внесение изменений в конфигурацию приводят к неправильному или нежелательному поведению, можно воспользоваться средством восстановления системы — компонентом, введенным в линейку операционных систем Windows NT® в системе Windows XP, чтобы восстановить системные файлы до состояния, в котором они находились в момент создания точки восстановления.

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

BitLocker

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

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

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

Для упрощения процедуры шифрования загрузочного тома (том, на котором находится каталог Windows), включая все его системные файлы и данные, в Windows Vista введен компонент шифрования диска Windows BitLocker, предназначенный для шифрования всего тома. В отличие от EFS, которая реализуется посредством драйвера файловой системы NTFS и работает на уровне файлов, BitLocker выполняет шифрование на уровне тома с помощью драйвера шифрования всего тома (FVE — Full Volume Encryption) (%Systemroot%\System32\Drivers\Fvevol.sys), как показано на диаграмме на рис. 4.

FVE представляет собой драйвер фильтра, поэтому он автоматически отслеживает все запросы операций ввода и вывода, которые система NTFS передает тому, шифруя блоки во время их записи и расшифровывая их во время чтения с помощью ключа шифрования всего тома (FVEK — Full Volume Encryption Key), назначенного тому во время его первоначальной настройки для использования компонента BitLocker. По умолчанию тома шифруются с использованием 128-разрядного ключа AES и 128-разрядного ключа рассеивателя. Поскольку шифрование и расшифровка выполняются на уровне системы ввода и вывода, находящейся ниже уровня системы NTFS, она воспринимает том как незашифрованный и не обязана знать о том, что компонент BitLocker активен. Однако при попытке чтения данных с тома без использования операционной системы Windows данные на томе выглядят как случайные.

Ключ FVEK шифруется с помощью главного ключа тома (VMK — Volume Master Key) и хранится на томе в области, специально отведенной для метаданных. При настройке компонента BitLocker предлагается ряд вариантов защиты ключа VMK, зависящих от возможностей оборудования системы. Если в системе имеется модуль доверенной платформы (TPM ), поддерживающий версию 1.2 спецификации TPM, и имеется соответствующая поддержка BIOS, ключ VMK может быть зашифрован либо с помощью TPM, когда система шифрует VMK с помощью ключа, хранящегося в TPM и ключа, хранящегося на флэш-устройстве USB, либо ключ может быть зашифрован с помощью ключа, хранящегося в TPM, и ПИН-кода, вводимого при загрузке системы. Для систем, в которых нет модуля TPM, BitLocker предлагает вариант шифрования ключа VMK с помощью ключа, хранящегося на внешнем флэш-устройстве USB. В любом случае необходим незашифрованный том емкостью 1,5 ГБ с системой NTFS, на котором хранятся диспетчер загрузки (Boot Manager) и база данных конфигурации загрузки (BCD).

Преимущество использования модуля TPM заключается в том, что в BitLocker используются функции TPM для гарантии того, что BitLocker не расшифрует ключ VMK и не разблокирует том, если BIOS или загрузочные файлы системы были изменены с момента активирования BitLocker. При первоначальном шифровании системного тома и при каждом обновлении любого из упомянутых компонентов BitLocker вычисляет хэши SHA-1 для этих компонентов и все хэши, называемые измерениями, сохраняет в разных регистрах конфигурации платформы (PCR) модуля TPM с помощью драйвера устройства TPM (%Systemroot%\Sys­tem32\Drivers\Tpm.sys). Затем модуль TPM используется для запечатывания ключа VMK. При выполнении этой операции используется хранящийся в TPM закрытый ключ для шифрования VMK и значения, хранящиеся в регистрах PCR, наряду с другими данными, которые BitLocker передает модулю TPM. Затем BitLocker сохраняет запечатанный ключ VMK и зашифрованный ключ FVEK в области метаданных тома.

При загрузке системы она выполняет измерение своего собственного хэширования и кода загрузки PCR и записывает хэш в первый PCR модуля TPM. Затем она хэширует BIOS и сохраняет это измерение в соответствующем PCR. В свою очередь BIOS хэширует следующий компонент из последовательности начальной загрузки, основную загрузочную запись (MBR) загрузочного тома, и эта процедура продолжается до тех пор, пока не будет измерен загрузчик операционной системы. Каждый последующий фрагмент кода, который выполняется, отвечает за измерение загружаемого им кода и за сохранение измерения в соответствующем регистре модуля TPM. Наконец, когда пользователь выбирает загружаемую операционную систему, диспетчер загрузки (Bootmgr) считывает зашифрованный ключ VMK с тома и выдает модулю TPM запрос на его раскрытие. Только в том случае, когда все измерения совпадают с теми, которые были сделаны при запечатывании ключа VMK, включая дополнительный ПИН-код, TPM успешно расшифровывает ключ VMK.

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

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

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

Поскольку центры сертификации берут плату за свои услуги и выполняют основные проверки происхождения кода, такие как проверка подлинности предприятия, довольно сложно создать анонимное вредоносное программное обеспечение, работающее в режиме ядра в 64-разрядной версии Windows Vista. Более того, вредоносная программа, которой удается пройти процедуру проверки, может, в принципе, оставить следы, ведущие к ее автору, в случае ее обнаружения в поврежденной системе. У компонента KMCS есть дополнительные применения, такие как предоставление информации группе Майкрософт, занимающейся интерактивным анализом сбоя, в случае возникновения подозрения о том, что драйвер содержит ошибку, вызывающую сбои пользовательских систем и разблокирование мультимедийного содержимого высокой четкости. Эти применения будут кратко описаны.

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

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

Windows выполняет также проверку соответствующих цепочек сертификатов вплоть до одной из служб выдачи корневых сертификатов, встроенных в загрузчик Windows и ядро операционной системы. Попытки загрузить неподписанный 64-разрядный драйвер невозможны в рабочей системе, поскольку в отличие от диспетчера Plug and Play, отображающего диалоговое окно с предупреждением, когда ему передается команда загрузить драйвер, не имеющий подписи, подтверждающей, что драйвер проходил проверку WQHL, 64-разрядная версия Windows Vista, каждый раз, когда она блокирует загрузку неподписанного драйвера, безмолвно записывает событие в журнал событий приложения проверки целостности кода, аналогичное показанному на рис. 5. 32-разрядная версия Windows Vista также проверяет подписи драйверов, но допускает загрузку неподписанных драйверов. Их блокирование привело бы к нарушению модернизированных систем Windows XP, которым требуются драйверы, которые были загружены в Windows XP, а также допускает поддержку оборудования, для которого существуют только драйверы Windows XP. Однако при выполнении загрузки неподписанного драйвера 32-разрядная версия Windows Vista также записывает события в журнал событий целостности кода.

Поскольку подписывание кода обычно используется для пометки кода в качестве версии, прошедшей тщательную официальную проверку, издатели, как правило, не стремятся подписывать тестовый код. Поэтому в Windows Vista включен режим тестового подписывания, который можно включать и отключать с помощью инструмента Bcdedit (описан в моей статье в мартовском выпуске TechNet Magazine за 2007 г.) и в рамках которого выполняется загрузка драйверов режима ядра, имеющих цифровую подпись, сделанную тестовым сертификатом, созданным собственным центром сертификации компании. Этот режим предназначен для использования программистами во время разработки кода. Когда операционная система Windows находится в этом режиме, на рабочем столе отображаются маркеры, подобные показанным на рис. 6.

Рис. 6 Режим тестового подписывания в операционной системе Windows Vista