https://github.com/0x00Alchemist/Deadwing

Хорошо, мы зарегистрировали свой хендлер. А как нам общаться, ебать? Платформа предоставляет два протокола для коммуникации, которые доступны нам как в 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. ???