Занят тут кое-какими слегка интересными вещами: смотрел, как и где винда хранит рантаймовые сервисы для рантаймовых драйверов.

Опытным путём была выявлена структура HAL_EFI_RUNTIME_SERVICES_BLOCK, которая, собственно, и формирует структуру с поинтерами на рантаймовые сервисы. Как можно догадаться — это далеко не полный список сервисов, так как некоторые не имеет смысла хранить, либо же не имеет смысла вызывать вовсе (SetVirtualAddressMap, например). Последнее, поле, предполагаю, относится к размеру блока, либо же к их количеству (хз, нужно больше смотреть, на физической машине, вероятно, будет другое значение). Также, судя по всему (да так и есть, если исходить из логических заключений), поинтеры на рантаймовые сервисы формируют ещё одну структуру (один из сервисов судя по всему не существует, земля ему пухом).

Занимательно, что за этой же структурой находится одна точно такая же, которая носит название HAL_IUM_EFI_WRAPPER_TABLE, что, судя из названия, предназначена для использования с включенным DeviceGuard. В себе она уже содержит поинтеры на функции с именами HalpIum* (например, HalpIumGetTime (рантаймовый сервис GetTime)).

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

Рассказал что-то возможно интересное, пора пропадать ещё на N-ное количество месяцев, my pancakes. 😏

P.S: только как дописал пост, заметил, что последнее поле имеет адрес самой структуры. Это постирония, ебать.

Дарова, блин! 👋👋👋
Мы давно с вами не виделись, пирожочечки!

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

Я занимался написанием SMM драйвера, что изначально казалось весьма сложной задачей, однако, по прошествию времени оказалось, что нет, это по сути более аутичное направление разработки (ну, как и вся около-прошивочное/embedded направление(я)) со своими приколами и постприколами. Ближе к сути со следующего абзаца.

Первым вопросом может стать коммуникация с "внешним миром" и SMM. У спецификации инициализации платформы есть несколько "официальных" предложений на этот счёт и ещё парочка неочевидных (один зависит от платформы).
Вся коммуникация, очевидно, происходит через SMI-хендлеры, которые, очевидно, регистрируются нами при первой инициализации SMM (DXE Foundation передаёт "список" драйверов платформы DXE Core, онный запускает SMM Core (не всегда первым)). Мы, в свою очередь, имеем 10 типов хендлеров (по спецификации), но только 4 нам интересны:
1. Root SMI - хендлеры, срабатывающие при каждом SMI, выброшенных платформой.
2. Child SMI - хендлеры, срабатывающие при явном указании SMM Core GUID данных хендлеров.
3. SW SMI - софтварные SMI, срабатывающие через триггер-порт B2, могут принимать данные через порт B3. Триггер-порты теоретически могут меняться, смотрите на FADT/FACP ACPI таблицу.
4. Periodic SMI - из названия, хендлеры, срабатывающие в период N времени.
5. SX SMI - хендлеры Sleep State (S0 - S5 или G1 -G3, если описывать комплексно).
6. USB SMI - хендлеры, что срабатывают при подключении USB устройств.
7. GPI SMI - General Purpose Input, не уверен за что они отвечают.
8. Standby SMI - хендлеры, что триггерятся на нажатие кнопки ожидания.
9. Power Button SMI - хендлеры, что триггерятся на нажатие кнопки питания.
10. I/O Trap SMI - хендлерры, обрабатывающие специфичные адреса/диапазоны I/O процессора.

Я работал с первыми тремя и самым удобным оказался в итоге второй вариант, так как для него завезён нормальный протокол в двух его версиях (1, 2). Последний имеет в себе возможность работать с виртуальными адресами (а ещё он реализован как отдельный драйвер на армах). Если мы работаем с рутовыми хендлерами, то их суть заключается в том, что они срабатывают при каждом выброшенном SMI. Это не совсем релевантно, так как им не очень удобно передавать пул памяти, в котором может содержаться необходимая информация (о пулах я скажу позже). Дебажить рутовые хендлеры также не сильно удобно при отладке бутовых фаз (DXE, BDS, TSL), так как, опять же, процессор в этих фазах выбрасывает их достаточное количество.
Интереснее обстоит вопрос с софтварными хендлерами (SW SMI). Видите ли, пирожочки, в основном отладка подобных вещей в первую очередь производится на QEMU и подобных вещах, а только потом на реальных машинах. Так вот, OVMF (образ прошивки для QEMU и подобных) не подразумевает реализацию протокола EFI_MM_SW_DISPATCH_PROTOCOL в виду некоторых хардварных особенностей. Этот протокол регистрируют "silicon-based" драйвера, которые не могут эмулироваться в виду тех или иных особенностей. В теории, нам ничего не мешает написать собственные драйвера или портировать один из предложенных (1, 2) с заменой и переработкой некоторых функций (например, этой), но это не входит в мои текущие задачи. Мы можем "эмулировать" работу софтварных хендлеров, регистрируя, например, рутовый хендлер, записывать в порт B2 номер хендлера и читать порт в хендлере, сравнивая значения из порта с нашим. На мой взгляд это кринжово и костыльно.

Хорошо, мы зарегистрировали свой хендлер. А как нам общаться, ебать? Платформа предоставляет два протокола для коммуникации, которые доступны нам как в SMM, так и в DXE, а также в последующих фазах, в том числе в рантайме, при условии, что указатель на протокол будет сконвертирован. У нас есть EFI_MM_COMMUNICATION_PROTOCOL и EFI_MM_COMMUNICATION2_PROTOCOL протоколы (1, 2), которые обращаются к SMM Core и триггерят (1, 2) нужный хендлер через сервисы SmiManage или Trigger (1, 2). Учитывая, что данные протоколы конвоируют данные, нам также необходимо хранить где-то данные для хендлера, которые будут позже конвоированы в пространство SMM. Платформа для таких вещей имеет несколько типов пулов: EfiRuntimeServicesData, EfiRuntimeServicesData, EfiReservedMemoryType, EfiACPIMemoryNVS (и вроде бы ещё EfiACPIReclaimMemory, если не ошибаюсь). С другими типами памяти протоколы не работают, так как не предоставляются фазе рантайма.
Где же выделять буфер для коммуникации? В любом месте, кроме как SMM, так как SMRAM закрывается и открывается отдельным протоколом (мы, технически, можем даже это контролировать, неся ущерб целостности платформы), а в эти окошки очень трудно попасть. Единственное релевантное решение, которое я придумал - написание промежуточного рантаймового DXE драйвера, который ловит регистрацию EFI_MM_COMMUNICATION_PROTOCOL/EFI_MM_COMMUNICATION2_PROTOCOL (1, 2), выбрасывает тестовый SMI в ивенте, который триггерит сервис ExitBootServices и ещё один ивент, что конвертирует указатель на проткол, пул памяти и пару функций, реализующих коммуникацию между режимами и публикует пакет данных для модулей ОС. Это удобно, тащемта, несмотря на то, что в итоге мой драйвер находится в HOB, который загружается DXE Core ещё раньше, чем SMM Core.
Я опущу ещё один метод, потому что хочу рассказать ещё о двух менее очевидных, а ко второму "официальному" вернусь позже. Мы можем общаться с "внешним миром" и SMM, неиронично, через NVRAM переменные, при условии, что у нас есть флаг EFI_VARIABLE_NON_VOLATILE. Это может быть удобно в том случае, если целевая ОС реализует возможность регистрировть такие пременные (кеширует сервисы напрямую, я рассказывал об этом здесь, где это можно увидеть на винде, например). Однако, при работе с SMI хендлерами мы не можем обращаться напрямую к рантаймовым сервисом, так как это "не кекурно" и вообще процессор выбросит #PF, потому что вызов данных сервисов будет за SMRAM (очень красиво cтавим классы). Поэтому, нам необходимо предварительно зарегистрировать коллбек на регистрацию протокола EFI_SMM_VARIABLE_PROTOCOL, только тогда мы можем общаться с рантаймом через NVRAM переменные. Мне, лично, этот метод кажется костыльным.
Есть ещё забавный вариант общаться через Save State (это по сути "карта" со всеми регистрами и их состояниями на момент срабатывания перырвания), кешируя в SMM драйвере EFI_MM_CPU_PROTOCOL протокол, я читал, что это работает на CSM системах с легаси прерываниями (например, INT15 D042). Я смотрел, как это работает, и работает оно не очень, подозреваю, что из-за эмуляции.
Перейдём к ещё одному специфическому методу коммуникации - мы можем регистрировать ACPI таблицы определённого типа (но не сразу, только по прошествию какого-то промежутка времени), выделяя физический буфер с типом EfiACPIMemoryNVS или EfiACPIReclaimMemory, эти таблицы позже будут опубликованы для ОС. Это требует от нас возможность регистрировать SW SMI хендлеры, которые уже не доступны при эмуляции. Этим методом пользуется TCG драйвер для работы с TPM. Увы, нет возможности это затестить сейчас.

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

Stay safe. 😅😅😅

da swag
😁😁😁