Системные рабочие потоки

При инициализации Windows создает несколько потоков в процессе System, которые называются системными рабочими потоками(system worker threads). Они предназначены исключительно для выполнения работы по поручению других потоков. Bo многих случаях потоки, выполняемые на уровне «DPC/dispatch», нуждаются в вызове таких функций, которые могут быть вызваны только при более низком IRQL. Например, DPC-процедуре, выполняемой в контексте произвольного потока при IRQL уровня «DPC/dispatch» (DPC может узурпировать любой поток в системе), нужно обратиться к пулу подкачиваемой памяти или ждать на объекте диспетчера для синхронизации с потоком какого-либо приложения. Поскольку DPC-процедура не может понизить IRQL, она должна передать свою задачу потоку, который сможет выполнить ее при IRQL ниже уровня «DPC/dispatch».

Некоторые драйверы устройств и компоненты исполнительной системы создают собственные потоки для обработки данных на уровне «passive», но большинство вместо этого использует системные рабочие потоки, что помогает избежать слишком частого переключения потоков и чрезмерной нагрузки на память из-за диспетчеризации дополнительных потоков. Драйвер устройства или компонент исполнительной системы запрашивает сервисы системных рабочих потоков через функцию исполнительной системы ExQueueWorkItemили IoQueueWorkItem.Эти функции помещают рабочий элемент(work item) в специальную очередь, проверяемую системными рабочими потоками.

Глобальные флаги Windows

Windows поддерживает набор флагов, который хранится в общесистемной глобальной переменной NtGlobalFlag,предназначенной для отладки, трассировки и контроля операционной системы. При загрузке системы переменная NtGlobalFlagинициализируется значением параметра GlobalFlag из раздела реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. По умолчанию его значение равно 0,и в системах с обычной конфигурацией глобальные флаги обычно не используются. Кроме того, каждый образ исполняемого файла имеет набор глобальных флагов, позволяющих включать код внутренней трассировки и контроля (хотя битовая структура этих флагов совершенно не соответствует структуре общесистемных глобальных флагов). Эти флаги не документированы, но могут пригодиться при изучении внутреннего устройства Windows.

LPC

LPC (local procedure call) - это механизм межпроцессной связи для высокоскоростной передачи сообщений. Он недоступен через Windows API напрямую и является внутренним механизмом, которым пользуются только компоненты операционной системы Windows. Вот несколько примеров того, где применяется LPC

· Windows - приложения, использующие RPC (документированный API), неявно используют и LPC, когда указывают локальный RPC - разновидность RPC, применяемую для взаимодействия между процессами в рамках одной системы.

· Некоторые функции Windows API обращаются к LPC, посылая сообщения процессу подсистемы Windows.

· Winlogon взаимодействует с процессом LSASS через LPC

· Монитор состояния защиты также взаимодействует с процессом LSASS через LPC

Трассировка событий ядра

Различные компоненты ядра Windows и несколько базовых драйверов устройств оснащены средствами мониторинга для записи трассировочных данных об их работе, используемых при анализе проблем в системе. Эти компоненты опираются на общую инфраструктуру в ядре, которая предоставляет трассировочные данные механизму пользовательского режима - Event Tracing for Windows (ETW). Приложение, использующее ETW, попадает в одну или более следующих категорий.

· Контроллер (controller)Начинает и прекращает сеансы протоколирования (logging sessions), а также управляет буферными пулами.

· Провайдер (provider)Определяет GUID (globally unique identifiers) для классов событий, для которых он может создавать трассировочные данные, и регистрирует их в ETW. Провайдер принимает команды от контроллера на запуск и остановку трассировки классов событий, за которые он отвечает.

· Потребитель (consumer)Выбирает один или более сеансов трассировки, для которых ему нужно считывать трассировочные данные. Принимает информацию о событиях в буферы в режиме реального времени или в файлы журнала.

Wow64

Wow64 (эмуляция Win32 в 64-разрядной Windows) относится к программному обеспечению, которое дает возможность выполнять 32-разрядные х8б-приложения в 64-разрядной Windows. Этот компонент реализован как набор DLL пользовательского режима.

· Wow64.dll - управляет созданием процессов и потоков, подключается к диспетчеризации исключений и перехватывает вызовы базовых системных функций, экспортируемых Ntoskrnl.exe. Также реализует перенаправление файловой системы (file system redirection) и перенаправление реестра и отражение (reflection).

· Wow64Cpu.dll - управляет 32-разрядным контекстом процессора каждого потока, выполняемого внутри Wow64, и предоставляет специфичную для процессорной архитектуры поддержку переключения режима процессора из 32-разрядного в 64-разрядный и наоборот.

· Wow64Win.dll - перехватывает вызовы системных GUI-функций, экспортируемых Win32k.sys.

11. Windows – диспетчер объектов: требования к нему, объекты исполнительной системы и их структура, методы объекта, описатель объекта и таблица описателей процесса, внутренние объекты, объекты исполнительной системы (executive objects), доступные Windows API и объекты ядра (kernel objects). Структура объектов — стандартные атрибуты заголовка объекта. Базовые сервисы объектов. Объекты типа — атрибуты объекта типа. Хранение объектов в памяти — временные (temporary) и постоянные (permanent). Имена объектов. Стандартные каталоги объектов. Пространство имен сеанса.

Диспетчер объектов

Реализованная в Windows модель объектов позволяет получать согласованный и безопасный доступ к различным внутренним сервисам исполнительной системы. Диспетчер объектов(object manager) - компонент исполнительной системы, отвечающий за создание, удаление, защиту и отслеживание объектов.

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

· реализовать общий, унифицированный механизм использования системных ресурсов;

· изолировать защиту объектов в одном участке операционной системы для соответствия требованиям безопасности класса C2;

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

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

· соответствовать требованиям различных подсистем окружения операционной системы - например, поддерживать наследование ресурсов родительских процессов дочерними (необходимо в Windows и POSIX) и имена файлов, чувствительные к регистру букв (требуется в POSIX);

· устанавливать единообразные правила сохранения объектов в памяти (т. е. объект должен быть доступен, пока используется какими-либо процессами).