Отложенный вызов процедуры (Deferred Procedure Call)

§ ISRs(процедуры обработки прерывания), работающие на определенном IRQL (DIRQLx), могут предотвратить выполнение других ISR на более нижних IRQLs

§ Это увеличивает время ожидания для системных прерываний

§ Чтобы уменьшить Задержку прерывания, ISRs:

§ Выполняют абсолютный минимум работ на DIRQLx

§ Запрашивают DPC выполнить объем работы на DISPATCH_LEVEL ()

§ Позволяют системе быстро обработать другие прерывания

§ DPCs используются, чтобы задержать обработку прерывания на более нижних IRQLs ()

§ Структура KDPC представляет DPC

§ Содержит функцию повторного вызова (подпрограмма DPC)

§ Структура KDPC поставлена в очередь в специальный список DPC CPU в KPCR.PrcbData.DpcListHead

§ Подпрограммы DPC выполняются:

§ В произвольном контексте потока в IRQL == DISPATCH_LEVEL

§ Используя специальный стек ЦП, указатель которого в KPCR.PrcbData.DpcStack

 

 

Асинхронный вызов процедуры (Asynchronous Procedure Call)

§ Используется для выполнения функции в контексте определенного потока

§ APC, выполненные на PASSIVE_LEVEL или APC_LEVEL

§ KTHREAD.ApcState. ApcListHead [] содержит список APCs, ожидающих потока

o Содержит начала списка (list heads) UserMode & KernelMode

§ Структура KAPC представляет APC

o KAPC вставлен в Очередь потока APC

o Организация очередей APC не вызывает поток к ожиданию аварийного завершения

§ Кроме случаев, когда target поток ждет в

alertable состоянии ожидания в обращении к WaitForSingleObjectEx (), SleepEx () и т.д.

§ Подпрограмма APC имеет приоритет по non-APC коду

 

§ Подпрограммы KAPC

o RundownRoutine – Выполняется, когда APC отброшен во время завершения потока

o KernelRoutine – Выполняется на APC_LEVEL

o NormalRoutine – Выполняется на PASSIVE_LEVEL

Типы APC(режим ядра)

 

§ Специальный режим ядра

o KAPC.KernelRoutine выполняется на APC_LEVEL

o KAPC.NormalRoutine == NULL

o Delivered перед APCs нормального режима ядра

§ Вставлен в очередь APC потоков после других специальных APCs

o Deliverable, если

§ IRQL == PASSIVE_LEVEL

§ Поток не находится в защищенной области (KTHREAD.SpecialApcDisable! = 0)

o Подпрограмма APC не может получить мьютексы, доступные в IRQL == 0

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

 

§ Нормальный Режим Ядра

o KAPC.NormalRoutine на PASSIVE_LEVEL

o Deliverable, если

§ IRQL == PASSIVE_LEVEL

§ Поток не находится в критической секции (KTHREAD.KernelApcDisable! = 0)

§ Поток не выполняет APC ядра

o Подпрограмме APC разрешено делать все системные вызовы

o Используется ОС для завершения IRP

Типы APC (Пользовательский режим)

 

§ Пользовательский режим

§ KAPC.NormalRoutine выполняется на PASSIVE_LEVEL

§ Deliverable, только если поток находится в alertable состоянии ожидания

§ Поток может ввести alertable состояние ожидания, вызвав

· WaitForSingleObectEx с Alertable = TRUE

· WaitForMultipleObjectsEx с Alertable = TRUE

§ Queued через подтверждение посредством API Win32 (QueueUserApc())

§ Используется ОС, чтобы выполнить подпрограммы завершения ввода-вывода пользовательского режима

§ KAPC режима ядра/пользовательского режима может содержать опцию KAPC.KernelRoutine

§ Выполняется в IRQL == APC_LEVEL

§ Выполняется перед NormalRoutine

§ Для APCs пользовательского режима KAPC.KernelRoutine и KAPC.NormalRoutine выполняются только, когда поток находится в пользовательском режиме alertable ожидания

Единицы работы

 

§ В ОС предусмотрен механизм to execute a custom driver provided

function на PASSIVE_LEVEL в контексте системного потока

§ WORK_QUEUE_ITEM использовался в NT4 и предшествующих

§ IO_WORKITEMs были представлены в Win2K

· Ссылка устанавливается на объект устройства так, чтобы она не была удалена, пока выполняется рабочая единица подпрограммы

 

Расположение Виртуального Адресного Пространства Режима Ядра

Пулы памяти

 

§ Выделение динамической памяти в режиме ядра осуществляется из пулов памяти, то есть из хипов в режиме ядра

§ Страничный пул – страничная память

§ Нестраничный пул – page locked физически фрагментированная память

(такой пул используется обработчиками прерываний)

§ Session Pool – особый страничный пул, в котором располагаются данные сессии

§ Специальный пул – страничный/нестраничный с возможностью обнаружения нарушения целостности данных (используется для отладки)

§ Страничные/нестраничные пулы растут до установленного максимума системы

§ Максимальный размер пулов задается при системном запуске в реестре на основании количества физической памяти в системе

§ У системы есть multiple страничные пулы во избежание сериализации вызовов пула

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

§ Это полезно для отладки повреждений и утечек данных пула

 

 

 

Структура данных пула

 

§ Система содержит структуру POOL_DESCRIPTOR для каждого пула

§ Переменная PoolVector содержит массив указателей, которые указывают на дескрипторы страничных/нестраничных пулов

§ Точка входа страничного пула указывает на массив дескрипторов пула

§ Точка входа нестраничного пула указывает на единственный дескриптор пула

 

§ Блокам пула предшествует структура POOL_HEADER которая содержит отслеживаемую информацию о выделенных и свободных блоках

§ POOL_HEADER содержит:

· Тег пула для блока пула

· Указатель EPROCESS, который является квотой, взимаемой за блок пула

· Индекс пула, которому блок принадлежит (только для страничных пулов)

· Размер блока пула и размер предыдущего блока

 

 

Расположение объектов

 

§ Данные объектов хранятся в нестраничном пуле

§ Диспетчер объектов использует известные теги для объектов

§ Может использоваться для идентификации объектов в пуле

§ Например, у объектов файла есть тег 'Файл'

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

§ Указатель на дескриптор защиты хранится в заголовке объекта

§ Таблица указателей размещается в страничном пуле. Каждый элемент таблицы:

§ описывается типом HANDLE_TABLE_ENTRY

§ содержит указатель на объект и биты Granted Access (с разрешенным доступом)