Windows x64 - путешествие из User в Kernel

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

Оглавление:

---

1. Контроль исполняемых потоков процессором​

Чтобы не возникало лишних вопросов, начнём с базовых основ.
Значит всякий процесс в ядре - это просто структура EPROCESS, где перечислены все выделенные ему системные ресурсы. А вот код исполняют уже потоки процесса, которые олицетворяет структура ETHREAD. Что примечательно, ЦП ориентируется исключительно на потоки и даже не знает, какому именно процессу они принадлежат. Далее под терминами "процесс" и "поток" мы будем подразумевать их структуры.

В процессах имеются по 2 кольцевых списка LIST_ENTRY - в первом лежат указатели на следующий и предыдущий процесс в системе (позволяют вести учёт активных), а во втором - линки на их собственные потоки. Вот, что думает на этот счёт отладчик WinDBG:


Всё-бы хорошо, только умиротворённый пейзаж портит системный планировщик. Каждые 0.02 сек (квант 20мс) он подкидывает на конвейер потоки соседних процессов из своей очереди, чтобы эмулировать многозадачность. За этот промежуток ЦП с тактовой частотой 2 ГГц успевает простучать 40 млн раз (2 млрд * 0.02), что равносильно выполнению ~20 млн простых инструкций. Этого более чем достаточно, чтобы утилита среднего звена полностью отработала свой код всего за 1 выделенный ей квант.

Но если поток приложения ожидает диалога с юзером, то 20 милли/сек ему по любому не хватит. Тогда планировщик приостанавливает наш поток, отдаёт управление следующему в очереди, и если нет других, возвращает наш обратно в прежнее состояние. Эту процедуру назвали "Context-Switch", и поскольку она требует переходов в ядро, инженеры стараются макс.оптимизировать её. Рассмотрим, как и при каких именно обстоятельствах это происходит.

1.1. Стек ядра и стек пользователя​

Межуровневая миграция потоков в нулевое кольцо и обратно требует обязательной смены стека, иначе любая малварь сможет легко проникнуть на защищённую территорию системы. Поэтому ещё на этапе создания потоков, кроме обычного стека в Ring(3), ОС сразу выделяет каждому из них индивидуальный свой стек и в ядерной памяти, а указатель на него сохраняет в поле "StackBase" их структур KTHREAD.


В доках говорится, что под стек-ядра каждому из юзер-потоков выделяется по 24 КБ, но у себя я вижу 40. При этом если открыть вкладку "Быстродействие" в диспетчере задач, то всего активных потоков 724. Тогда выходит, что на карманные расходы всем потокам ОС выделяет сейчас из своего невыгружаемого пула ~28 МБ памяти, и это только на ядерные стеки, а ведь ещё имеются сами структуры EPROCESS, и у каждой по несколько ETHREAD размером 1200 байт.

В свою очередь, у лог.ядер ЦП имеется личное пространство PCR (Processor Control Region), на которое смотрит их регистр IA32_GS_BASE - этот регион описывает структура KPCR. Когда система планирует отправить юзер-поток в Kernel, она сначала прописывает указатель на него в поле "CurrentThread" структуры KPCR так, что ядро ЦП всегда знает, по какому именно адресу нужно искать стек вновь прибывшего потока в своём невыгружаемом пуле.

У соседнего cpu(2) уже свой регион KPCR, поэтому никаких конфликтов не возникает и планировщик ОС волен тасовать потоки по любым ядрам процессора, в зависимости от их занятности на текущий момент - если первый квант поток отработал на cpu(3), то на втором кванте он может попасть на cpu(1), и т.д. Схематично эта связь представлена ниже:


Кстати размер невыгружаемого в своп NonPagedPool ограничен, и этот фактор влияет на макс.возможное число потоков в системе. В пакете "SysinternalsSuite" есть тулза TestLimit64.exe, и будучи запущенная с ключом(-t) она в цикле порождает треды до тех пор, пока не нарвётся на исключение. Так вот на своей Win7 с 16 ГБ памяти ОЗУ я получил лимит потоков 360.000 штук, при этом невыгружаемый пул ядра динамически увеличился с 75 ровно до 600 МБ (походу это предел). Для справки, на системах х32 этот лимит застрял на отметке всего 2.000.

Пользовательский поток может переходить в ядро по нескольким причинам, которые делятся на синхронные по времени (кратно 20мс = квант), и непредсказуемые асинхронные, например когда происходит какое-нибудь исключение в коде (типа ошибка доступа к памяти), внезапно возникнет прерывание от физ.девайсов клавиатура-мышь-etc, а так-же при вызовах API-функций ядра через шлюз Ntdll.dll. Такая причинно-следственная связь отражается и на самом механизме перехода в ядро.

1.2. Сегмент состояния задачи TSS​

На системах х32, за смену уровней привилегий Ring(3-0) полностью отвечал ЦП на аппаратном уровне. Процедура начиналась с того, что в момент исключения все регистры текущего потока система скопом сохраняла в сегмент TSS, а процессор считывал их от туда. Ключевую роль играли поля Esp+Ss0 в структуре TSS, в которых планировщик передавал процессору указатель на стек-ядра переходного потока из его KTHREAD.


Но сейчас на х64 инженеры отказались от такой схемы, и сегмент TSS играет чисто символическую роль. В нём остались всего 2 актуальных поля - это как и прежде Rsp0, а так-же массив IST из восьми 8-байтных значений. Вообще процессоры х86 поддерживают 4 уровня защиты Ring(0.1.2.3), хотя по факту используют лишь кольца 0 и 3. Поэтому стеки ядра для уровней Rsp1 + Rsp2 в сегменте TSS64 никогда не используются.

В TSS64 появилась новая "Interrupt Stack Table" - IST. Это 7 указателей на резервные стеки для обработки критических аппаратных сбоев, например рекурсивная ошибка DoubleFault(#DF) или MachineCheck(#MC), чтобы процессор мог гарантированно обработать исключение, даже если основной стек ядра был полностью разрушен в труху.

Сегмент TSS имеет свой дескриптор в глобальной таблице GDT, где указывается его база и лимит - система сохраняет их в регистре TR процессора. Обратите внимание на размер/лимит нового сегмента 0x68=104 байта, хотя раньше был 0x20ac=8.364 байта. Это потому, что огромная карта доступа к портам "IoMap" в хвосте, вместе с картой перенаправления прерываний была полностью удалена, т.к. прежде использовалась в вирт.режиме V86 процессора, который ныне не поддерживается вообще.


Когда поток выполняется в Ring(3) и происходит прерывание, исключение или вызов api, ЦП должен переключиться на стек ядра. В этот момент он автоматически считывает поле Rsp0 из TSS и загружает его значение в регистр RSP. Это обеспечивает безопасный вход в ядро, не затрагивая пользовательский стек. Таким образом, Rsp0 используется только для первоначального переключения стека при входе в Kernel из пользовательского режима.

Процессор никогда не записывает никаких значений в TSS, а лишь читает то, что записала система из поля "KernelStack" структуры KTHREAD потока, в момент возникновения исключений/прерываний в нём. У каждого лог.ядра ЦП свой сегмент TSS и свои регистры TR, т.е. они не делят общий.


2. Асинхронные переходы

Когда в исполняемом потоке происходит исключение, срабатывает системная ловушка "Trap" и управление передаётся обработчику форс-мажорного обстоятельства. В этот момент ЦП должен сохранить контекст регистров прерванного потока (чтобы восстановить его работу позже). Но куда сохранять-то, ведь TSS для этих целей уже не используется?

Поэтому ОС бежит здесь вперёд паровоза, заранее подготавливая всё к такой ситуации. Ещё на этапе создания потока (сразу после выделения ему стека-ядра), в поле "TrapFrame" структуры KTHREAD система сохраняет указатель на кадр-ловушки в этом стеке, куда и сбрасываются все регистры потока про запас. На рис.ниже отображён этот фрейм, а значение регистра RSP указано уже после его заполнения, т.к. изначально находится внизу и двигается вверх:


Поскольку вариантов переходов в ядро здесь всего три (исключение, прерывание, системный вызов), ОС обрабатывает их немного по разному, но во всех случаях первым вступает в дело сам ЦП, который на аппаратном уровне сбрасывает во-фрейм ловушки 5 основных регистров - это пары cs:rip, ss:rsp, и регистр флагов rflags. Процессор начинает пушить их в стек первыми, на каждом шаге двигая rsp всё выше-и-выше к лимиту, поэтому в структуре KTRAP_FRAME эти 5 регистров находятся в самом конце - вот её формат:


Теперь рассмотрим, на каких этапах и какими функциями заполняется остальная часть KTRAP_FRAME.

2.1. Системные вызовы "syscall"

Когда поток вызывает api типа CreateFile(), процессор переходит по адресу, который жёстко прошит в MSR-регистре IA32_LSTAR=0xC0000082. В нём лежит указатель на функцию ядра nt!KiSystemCall64(), которая и получит первой управление от пользовательской syscall. Она сразу резервирует место в стеке под KTRAP_FRAME и вручную заполняет его - вот фрагмент.

Здесь на входе встречает нас инструкция swapgs. Регистр GS под юзером указывает на ТЕВ текущего потока (Thread Environment Block), но в ядре он должен смотреть на структуру KPCR процессора. Так вот swapgs на входе как-раз меняет их значения местами, а на выходе опять восстанавливает. Значение ядра берётся из MSR-регистра IA32_GS_BASE=0xC0000101:


2.2. Прерывания и исключения

В целом, программные исключения "Fault" и аппаратные прерывания "Interrupt" обрабатываются одинаково - через таблицу IDT (Interrupt Dispatch Table). Это массив из 256 структур KIDTENTRY64 по 16-байт каждая (итого 4КБ), а его база в памяти лежит в структуре KPCR процессора (система сохраняет в регистре IDTR). Первые 20=0x14 векторов в таблице всегда резервируются под исключения и ловушки, а остальные система раздаёт обработчикам прерываний от физ.устройств.


Раньше можно было прямо в WinDBG узнать адрес обработчиков прерываний ISR от физ.устройств типа мышь, клава, диск, сеть и прочих. Но теперь появилась защита от уязвимостей Meltdown и Spectre, в результате чего доступ только через затенённое пространство ShadowSpace (см.жёлтый блок выше). В отладчике есть и окольные пути, например чз объекты драйверов, но сейчас речь не о том, т.к. сути это не меняет.

Когда поток нарывается на исключение/прерывание, система передаёт управление на вектор из таблицы IDT, а функции его обработки формируют уже KTRAP_FRAME для фиксации состояния прерванного потока. Вот пролог самой первой процедуры из списка IDT (в остальных аналогично) - как видим, в нём много общего с предыдущей KiSystemCall64():


2.3. Волатильные регистры

В отличии от х32, сейчас Win не сохраняют буквально все регистры процессора в TRAP_FRAME. Неволатильные RBX,RDI,RSI,RBP,R12-R15 намеренно опускаются для оптимизации скорости. Если ядру в процессе обработки прерывания всё же потребуется их изменить, оно сохраняет их отдельно. Но здесь возникает вопрос, что означают термины Volatile и NonVolatile?

Это деление определяет, кто несёт ответственность за сохранение регистра при вызове функций, и какие из них попадают в KTRAP_FRAME при входе в ядро.

1. Волатильные: RAX,RCX,RDX,R8,R9,R10,R11,XMM0–15
Это регистры, которые вызываемая WinAPI имеет право перезаписать без предварительного сохранения. Если нам как вызывающим значения этих регистров ещё нужны, придётся самостоятельно сохранить их до вызова функции. В _fastcall первые 4 аргумента передаются в RCX,RDX,R8,R9, а в регистре RAX функция возвращает результат. Пара R10-11 черновики "scratch", которые api может использовать для временных вычислений.

2. Не волатильные: RBX,RBP,RSI,RDI,RSP,R12–R15
Их вызываемая функция обязана сохранить и восстановить перед возвратом управления. Они часто используются для хранения всякого рода переменных (указателей на структуры, счетчиков циклов и т.д.). Если-бы любая функция могла их безнаказанно рипать, нам пришлось-бы сохранять их вручную перед каждым вызовом, что крайне неудобно.

3. Синхронные переходы по окончании кванта потока

Ну и последний вариант - это переход юзер-потока в ядро при переключение планировщиком. Здесь уже контекст сохраняется не в прежнюю структуру KTRAP_FRAME, а в недокументированную KSWITCH_FRAME, которой нет даже в публичных символах *.pdb отладчика WinDBG. После входа потока в ядро, структура заполняется вполне прозрачной ассемблерной процедурой nt!KiSwapContext(), а потому дизассемблировав последнюю можно собрать KSWITCH_FRAME самим:

В отличие от KTRAP_FRAME, которую частично заполняет cpu, KSWITCH_FRAME создаётся исключительно программно. Обратите внимание, что здесь сохраняются только неволатильные регистры. В зависимости от причины переключения контекста, волатильные сохраняются в разных местах и разными компонентами. Здесь есть всего 2 сценария:


В среднем, на современных ЦП вся процедура "Context Switch" занимает до 5 мкс = 0.000005 сек, что эквивалентно нескольким тысячам тактов процессора. Точное время зависит от типа переключения (внутри одного процесса или между разными) и архитектуры ОС. Входит-ли время смены контекста в выделенный потоку квант? Ответ - нет! ..поскольку квант это чистая продолжительность работы потока. Алгоритм выглядит примерно так:


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

4. Выводы

Зачем это знать исследователю?
Ну во-первых отладка ядра. При анализе дампов памяти BSOD, вызовы KiSwapContext() часто находятся на макушке стека потоков, находящихся в ожидании Waiting. Понимание фреймов ловушек Trap и Switch помогает восстановить состояние регистров спящих потоков. А во-вторых разработка драйверов и руткитов. Мониторинг или подмена данных в структурах контекста позволяет низкоуровневому коду осуществлять перехват управления потоками ядра, или скрывать своё присутствие. В общем были-бы знания, а применение им обязательно найдётся. Всем удачи, пока!

Ссылки по теме:
https://medium.com/windows-os-internals/windows-internals-thread-management-part-1-9f4227a9e17c
Exploiting WRMSR in vulnerable drivers