Разделение состояния
Разделение состояний — это улучшенная модель обслуживания и безопасности, которая использует более четкие границы безопасности:
- Повышение безопасности ключевых системных областей
- Включение более быстрых и более чистых обновлений и сбросов системы
Эта модель используется во всех образах ос фабрики. Границы безопасности классифицируются следующими состояниями:
State | Description | Примеры |
---|---|---|
Неизменный | Эта область не может быть постоянно изменена, за исключением самой операционной системы. |
|
Мутируемое, высокое значение | Вы можете внести изменения и ожидать их сохранения после перезагрузки или обновления, но не после сброса системы. |
|
Изменяемое, низкое значение | Вы можете внести изменения, но они исчезнут после перезагрузки или сброса системы. | Некоторые компоненты могут потребоваться для записи в кусты реестра, такие как HKLM\SYSTEM и HKLM\SOFTWARE . Эти области реестра загружаются как переменные, поэтому компоненты по-прежнему могут выполнять операцию записи для определенной среды выполнения. После следующей перезагрузки изменения исчезнут. |
Пользовательские данные | Можно изменить. Каждый профиль данных пользователя шифруется в отдельной секции, поэтому изменения влияют только на пользователя, вошедшего в систему. |
|
Для заводских тестов можно хранить файлы журналов и другие тестовые файлы в разделе данных или в %PROGRAMDATA%
.
Нарушения разделения состояния
Нарушения разделения состояния возникают при:
- Компонент пытается записать в файловую систему в томе MainOS.
- Компонент записывается в кусты реестра или
HKLM\SOFTWARE
в нееHKLM\SYSTEM
.
Для разработки компонентов, которые соответствуют этим правилам, Windows может регистрировать каждый раз, когда компонент пытается записать в любое из этих расположений.
Обратите внимание, что только потому, что Windows отслеживает операцию записи, не обязательно означает, что существует проблема: компонент иногда может намеренно записывать HKLM\SYSTEM
в кусты реестра, HKLM\SOFTWARE
ожидая, что изменение будет неустойчивым.
Инструментирование
Существует несколько методов сбора журналов действий реестра и файловой системы. Определение правильного метода зависит от варианта использования, и когда в последовательности загрузки драйвер становится активным. Ниже приведена таблица, которая содержит сводку по использованию каждого метода для поиска нарушений разделения состояния и изоляции драйверов.
Способ | Когда нужно запустить? | Что он находит? |
---|---|---|
Средство автоматического ведения журнала ранней загрузки | Хотите найти нарушения файлов, которые не удается найти с помощью средства проверки драйверов или хотите увидеть нарушения файлов и реестра в той же трассировке. | Все нарушения файлов и большинство нарушений реестра |
Средство ведения журнала по запросу | Хотите найти нарушения файлов, которые не удается найти с помощью средства проверки драйверов или хотите увидеть нарушения файлов и реестра в той же трассировке. | Все нарушения файлов и большинство нарушений реестра |
Трассировка загрузки | Хотите иметь подробные сведения о стеке, которые приводят к нарушению | Все операции файлов и реестра независимо от того, являются ли они нарушением или нет |
Проверки изоляции драйверов проверяющего драйвера | Хотите найти все нарушения реестра во время запуска устройства, универсального тестирования драйверов и (или) сертификации | Нет нарушений файлов и всех нарушений реестра |
Представление нарушений в режиме реального времени
Самый простой способ отслеживания нарушений разделения состояний — проверить трассировки событий для Windows (ETW) в режиме реального времени на портале устройств Windows.
Примечание.
Драйвер фильтра, предоставляющий эту телеметрию, может загружаться после компонента. Если компонент выполняется в начале процесса загрузки, необходимо ознакомиться со следующим разделом.
- Войдите на портал устройств Windows, на тестируемом устройстве
- Перейдите на вкладку "Ведение журнала ETW" слева.
- В разделе "Пользовательский поставщик" включите следующий поставщик: d6e1490c-c3a6-4533-8de2-18b16ce47517 .
- Повторно выполните сценарий. Нарушения будут отображаться в таблице.
- При сборе достаточных данных нажмите кнопку "Сохранить в файл ", чтобы получить текстовый файл (.csv), содержащий захваченные нарушения. Часто проще работать с скачанными данными, чем выполнять анализ в режиме реального времени.
Ранний загрузочный autoLogger
Используйте функцию автолога ранней загрузки для записи трассировок трассировки etW для операций, выполняемых на ранних этапах загрузки:
Запустите tracelog, чтобы настроить автолог для прослушивания GUID поставщика: d6e1490c-c3a6-4533-8de2-18b16ce47517.
Задайте для буферов значение 128 килобайт, не менее 12 буферов и максимум 34 буферов (более низкие значения могут привести к удалению событий).
Для guid сеанса можно создать GUID с помощью
uuidgen
, а затем добавить знак числа (#) перед ним или указать имя файла, включающее GUID.Файл журнала можно сохранить в любом месте, хотя мы рекомендуем использовать расположение в папках данных пользователя или приложения, например
-f %ProgramData%\Fabrikam\log.etl
.Tracelog.exe -addautologger StateSeparationViolationsAutologger -sessionguid #aabbccdd-1234-5678-90ab-a00bb00ccdd -f %ProgramData%\Fabrikam\log.etl -guid #d6e1490c-c3a6-4533-8de2-18b16ce47517 -b 128 -min 12 -max 34
Перезагрузите устройство, чтобы начать сеанс трассировки AutoLogger
Остановите автологе:
Tracelog.exe -stop StateSeparationViolationsAutologger
Получите файл ETL и просмотрите данные:
a. Захватить значение каталога ProgramData устройства (например,
E:\ProgramData
).cmd-device -InformationVariable echoInfo echo %ProgramData% $deviceProgramData = $echoInfo[0]
b. Используйте это значение, чтобы скопировать ETL-файл с устройства на локальный компьютер. Пример:
PS C:\> getd E:\ProgramData\Fabrikam\log.etl C:\hostdir\log.etl
Просмотрите данные о действиях журнала трассировки с помощью Анальзиера производительности Windows (WPA) или других средств.
Средство ведения журнала по запросу
Используйте средство ведения журнала по запросу для записи трассировки etw по запросу.
Настройте сеанс ведения журнала для прослушивания GUID поставщика d6e1490c-c3a6-4533-8de2-18b16ce47517:
Tracelog.exe -start StateSeparationViolations -f <path to save ETL> -guid #d6e1490c-c3a6-4533-8de2-18b16ce47517
Повторно выполните сценарий или выполните тест (если устройство не перезагрузится).
Остановите сеанс ведения журнала.
Tracelog.exe -stop StateSeparationViolations
Скопируйте файл ETL из устройства.
PS C:\> getd C:\ProgramData\Fabrikam\log.etl C:\hostdir\log.etl
Откройте файл журнала и просмотрите данные о действиях журнала трассировки с помощью Windows Анализатор производительности.
Трассировка загрузки
При правильной настройке ранней трассировки трассировки трассировки ETW все операции реестра и (или) файлов можно записывать в трассировке и содержать стеки для каждой операции, детализируя путь кода, ведущий к этой операции реестра.
Регистрация трассировки загрузки (реестра, fileio или обоих)
wpr -boottrace -addboot registry wpr -boottrace -addboot fileio
Перезагрузите устройство, чтобы начать запись трассировки.
Снова подключитесь к устройству с помощью TShell.
Остановите трассировку:
wpr -boottrace -stopboot <path where to write ETL>
Скопируйте файл ETL из устройства.
PS C:\> getd C:\<path on device to the>\log.etl C:\hostdir\log.etl
Откройте файл журнала и откройте данные действия ведения журнала трассировки с помощью Windows Анализатор производительности.
В WPA сообщите ему загрузить символы, чтобы двоичный файл, который изучается, можно разрешить в трассировках стека, а затем открыть сводную таблицу реестра.
Мы рекомендуем отфильтровать таблицу, чтобы отобразить только операции с кустами SYSTEM и SOFTWARE. При просмотре столбца "базовое дерево ключей" разверните раздел REGISTRY и MACHINE. Выберите систему и ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ, щелкните правой кнопкой мыши и выберите "Фильтр к выбору".
Рекомендуется отфильтровать таблицу только для операций, в которых стек включает в себя исследование двоичного файла. Эту фильтрацию можно выполнить поверх фильтрации только к рекомендуемой выше системе и программному кусту. Щелкните столбец Stack и откройте поле поиска. Введите имя исследуемого двоичного файла и нажмите кнопку "Найти все". Щелкните правой кнопкой мыши одну из выделенных строк в стеке, в котором содержится двоичное имя, и выберите "Фильтр к выбору".
Проверки изоляции драйвера проверки драйвера проверки драйвера
Средство проверки драйверов (DV) — это средство, которое поставляется с Windows, которое используется для отслеживания драйверов для неправильных вызовов функций или действий, которые могут повредить систему. Начиная с сборки ОС 19568, средство проверки драйверов имеет новые функции для поддержки разработчиков драйверов Windows путем мониторинга нарушений требований к изоляции пакетов драйверов. Изоляция пакетов драйверов — это основные драйверы требований, которые должны соответствовать системам операционной системы фабрики, чтобы соответствовать требованиям к разделению состояний.
Средство проверки драйверов будет отслеживать неправильные операции чтения и записи реестра, которые не разрешены в системах операционной системы фабрики. Используйте это средство на ранней стадии разработки драйверов, чтобы понять и исправить, где компонент нарушает требования к изоляции драйверов.
Синтаксис
Примечание.
При включении в системе фабрики ОС см. статью "Подключение с помощью SSH" для удаленного подключения к системе "Фабрика ОС" через SSH
verifier /rc 33 36 /driver myDriver.sys
Это позволит проверить изоляцию драйверов на целевом драйвере (myDriver.sys). Вы также можете выбрать несколько драйверов, разделив список пробелом:
verifier /rc 33 36 /driver myDriver1.sys myDriver2.sys
Перезагрузка потребуется для включения параметров проверки. Для этого можно указать следующее:
shutdown /r /t 0
Ожидаемое поведение — режим телеметрии:
На начальных этапах запуска драйвера рекомендуемое поведение этих проверок — это режим телеметрии. Это поведение по умолчанию и предоставляет разработчикам возможность просматривать все нарушения без проверки ошибки, нарушающей ход выполнения.
Рекомендуется включить проверки изоляции драйвера DV с помощью синтаксиса, указанного в приведенном выше разделе, с подключенным отладчиком ядра. После включения перезагрузки параметры DV вы сможете увидеть нарушения в выходных данных отладчика ядра.
Ниже приведены несколько примеров сценариев нарушения требований к изоляции драйвера и типичных выходных данных:
Сценарий: ZwCreateKey с полным абсолютным путем:
"DRIVER_ISOLATION_VIOLATION: имя> драйвера: <операции реестра не должны использовать абсолютные пути. Обнаружено создание неразрешенного раздела реестра "\Registry\Machine\SYSTEM"
Сценарий: ZwCreateKey с помощью пути относительно дескриптора, который не является утвержденным API:
"DRIVER_ISOLATION_VIOLATION: имя> драйвера: <операции реестра должны использовать только маркеры ключей, возвращаемые из API WDF или WDM. Обнаружено создание неразрешенного раздела реестра "\REGISTRY\MACHINE\SYSTEM\SomeKeyThatShouldNotExist"
Используйте режим телеметрии, чтобы установить базовые показатели всех нарушений для компонента и начать исправлять их по одному, тестирование по мере использования.
Ожидаемое поведение — режим bucheck:
Далее в процессе разработки драйверов может быть полезно включить проверки изоляции драйверов в режиме, который приведет к очевидному нарушению. DV можно настроить для вызова проверки при возникновении нарушения.
Это приведет к созданию дампа памяти, который содержит точные сведения о том, где произошло нарушение. Чтобы включить DV в режиме проверки ошибок, используйте следующий синтаксис:
verifier /onecheck /rc 33 36 /driver myDriver1.sys
Этот режим полезен, когда драйвер приближается к рабочей готовности и проходит заключительные этапы проверки и тестирования.
Максимизация путей кода:
Правила изоляции драйверов DV можно включить во время выполнения IHV существующих платформ тестирования. Это поможет максимизировать пути кода, выполняемые тестируемым драйвером.
Основные сведения об устройствах с помощью командной строки — это хороший базовый план тестов для выполнения типичных путей кода для драйвера. Разработчики могут включить эти тесты с проверкой изоляции драйвера DV, чтобы максимально увеличить потенциал перехвата нарушений изоляции драйвера как можно раньше.
Режим разработки: отключение принудительного применения
В целях разработки можно отключить принудительное разделение состояния, выполнив команду в режиме разработки разделения состояний. Это позволяет разрабатывать, тестировать и запускать приложения и драйверы (например, тестовые приложения фабрики), которые не соответствуют требованиям.
В режиме разработки:
- Раздел MainOS доступен для записи.
- Изменения в
HKLM\SYSTEM
, аHKLM\SOFTWARE
также сохраняются во время перезагрузки. - Windows продолжает отслеживать действия, которые в противном случае нарушают правила разделения состояний.
Режим разработки можно настроить во время создания образа, заменив функцию: STATESEPARATION_ON
на STATESEPARATION_DEVMODE
.
В следующей таблице описаны различия между каждым режимом.
Режим разделения состояния | Неизменяемый доступ к файловой системе | Неизменяемый доступ к реестру |
---|---|---|
Режим принудительного применения | Запись не разрешена | Изменения реестра не сохраняются во время перезагрузки |
Предупреждение о нарушении в выходных данных ETW и отладчике | Предупреждение о нарушении в выходных данных ETW и отладчике | |
Режим разработки | Разрешено чтение и запись | Изменения реестра сохраняются во время перезагрузки |
Предупреждение о нарушении в выходных данных ETW и отладчике | Предупреждение о нарушении в выходных данных ETW и отладчике |