Efi файл что это
Настройка UEFI-загрузчика. Самое краткое руководство в мире
Как устроена загрузка современных ОС? Как при установке системы настроить загрузку посредством UEFI, не утонув в руководствах и ничего не сломав?
Я обещал «самое краткое руководство». Вот оно:
TL;DR не надо прописывать путь к загрузчику в новых загрузочных записях UEFI — надо файл загрузчика расположить по стандартному «пути по-умолчанию», где UEFI его найдет, и вместо загрузочного меню UEFI пользоваться меню загрузчика, которое гораздо проще и безопаснее настраивается
Как делать не надо
Есть, на самом-то деле, несколько способов настроить UEFI-загрузку. Я начну с описания других вариантов — чтобы было понятно, как (и почему) делать не надо. Если вы пришли за руководством — мотайте в самый низ.
Не надо лезть в NVRAM и трогать efivars
Наиболее «популярная» процедура установки загрузчика в систему такова: установщик ОС создаёт специальный раздел, на нём — структуру каталогов и размещает файлы загрузчика. После этого он с помощью особой утилиты (efibootmgr в linux, bcdedit в windows) взаимодействует с прошивкой UEFI-чипа, добавляя в неё загрузочную запись. В этой записи указывается путь к файлу загрузчика (начиная от корня файловой системы) и при необходимости — параметры. После этого в загрузочном меню компьютера появляется опция загрузки ОС. Для linux существует возможность вообще обойтись без загрузчика. В загрузочной записи указывается путь сразу к ядру вместе со всеми параметрами. Ядро должно быть скомпилировано с опцией EFISTUB (что давно является стандартом для большинства дистрибутивов), в этом случае оно содержит в себе заголовок «исполняемого файла EFI», позволяющий прошивке его запускать без внешнего загрузчика.
При старте системы, когда пользователь выбирает нужную ему загрузочную запись, прошивка UEFI сперва ищет на прописанном в этой записи диске особый EFI-раздел, обращается к файловой системе на этом разделе (обязательно FAT или FAT32), и запускает загрузчик. Загрузчик считывает из файла настроек свой конфиг, и либо грузит ОС, либо предоставляет загрузочное меню. Ничего не замечаете? Да, у нас два загрузочных меню — одно на уровне прошивки чипа UEFI, другое — на уровне загрузчика. В реальности о существовании второго пользователи могут даже не догадываться — если в меню всего один пункт, загрузчик Windows начинает его грузить без лишних вопросов. Увидеть экран с этим меню можно, если поставить вторую копию Windows или просто криво её переустановить.
Обычно для управления загрузочными записями руководства в интернете предлагают взаимодействовать с прошивкой UEFI. Есть аж пять основных вариантов, как это можно сделать: efibootmgr под linux, bcdedit в windows, какая-то софтина на «Маках», команда bcfg утилиты uefi shell (запускается из-под UEFI, «на голом железе» и без ОС, поскольку скомпилирована в том самом особом формате) и для особо качественных прошивок — графическими средствами UEFI (говоря популярным языком, «в настройках BIOS»).
За всеми вышенаписанными «многобуков» вы могли легко упустить такую мысль: пользователь, чтобы изменить настройки программной части (например, добавить параметр запуска ОС), вынужден перезаписывать flash-память микросхемы на плате. Есть ли тут подводные камни? О да! Windows иногда способна сделать из ноутбука кирпич, linux тоже, причём разными способами. Качество прошивок часто оставляет желать лучшего — стандарты UEFI либо реализованы криво, либо не реализованы вообще. По логике, прошивка обязана переживать полное удаление всех переменных efivars без последствий, не хранить в них критичных для себя данных и самостоятельно восстанавливать значения по-умолчанию — просто потому что пользователь имеет к ним доступ, и вероятность их полного удаления далека от нуля. Я лично в процессе экспериментов неоднократно (к счастью, обратимо) «кирпичил» свой Lenovo — из загрузочного меню исчезали все пункты, включая опцию «зайти в настройки».
Работа с загрузочными записями UEFI — тоже не сахар. К примеру, утилита efibootmgr не имеет опции «редактировать существующую запись». Если ты хочешь немного изменить параметр ядра — ты удаляешь запись целиком и добавляешь её снова, уже измененную. При этом строка содержит в себе двойные и одинарные кавычки, а также прямые и обратные слеши в не особо очевидном порядке. Когда я наконец заставил эту магию работать — я сохранил её в виде bash-скриптов, которые до сих пор валяются у меня в корневой ФС:
Не надо использовать GRUB
Это чёртов мастодонт, 90% функциональности которого предназначено для дисков с MBR. Для настройки необходимо отредактировать ряд файлов, после чего выполнить команду генерации конфига. На выходе получается огромная малопонятная нормальному человеку простыня. В составе — гора исполняемых файлов. Ставится командой, которую просто так из головы не возьмешь — надо обязательно лезть в документацию
Для сравнения — самый простенький UEFI-bootloader, который есть в составе пакета systemd, ставится командой
Эта команда делает ровно две вещи: копирует исполняемый файл загрузчика на EFI-раздел и добавляет свою загрузочную запись в прошивку. А конфиг для неё занимает ровно СЕМЬ строчек.
«Самое краткое руководство» — чуть более подробно
Загрузочное меню надо реализовывать на уровне загрузчика — править текстовые конфиги гораздо проще и безопасней.
Загрузочная запись нам не нужна — дело в том, что при выставлении в настройках BIOS загрузки с диска прошивка UEFI сначала ищет на нём EFI-раздел, а затем пытается исполнить файл по строго фиксированному адресу на этом разделе: /EFI/Boot/BOOTX64.EFI
Что такое «EFI-раздел»? В теории, он должен иметь особый тип «EFI System» (ef00). На практике, годится первый раздел на GPT-диске, отформатированный в FAT32 и имеющий достаточно места, чтобы разместить загрузчик и вспомогательные файлы (если есть).
Пункт 3: «Скачиваем из интернета любой UEFI-загрузчик». Что это значит? Загрузчик — это просто исполняемый файл определенного формата, к которому в комплекте идет конфиг. К примеру, если у вас есть под рукой установленный пакет с systemd — файл загрузчика можно найти по адресу /usr/lib/systemd/boot/efi/systemd-bootx64.efi, переименовать его в bootx64.efi и скопировать в /EFI/Boot/ на EFI-разделе. Нет под рукой systemd? Скачайте архив с сайта Archlinux. Или с репозитария Ubuntu. Или Debian. Есть под рукой система с Windows? Возьмите виндовый загрузчик оттуда, тоже сгодится )) Если сумеете настроить, я честно говоря не пробовал.
Пункт 4: «Настроить конфиг». Как и обычная программа, когда загрузчик запускается — он ожидает найти по определенным путям файлы конфигурации. Обычно эту информацию легко найти в интернете. Для загрузчика systemd-boot нам необходимо в корне EFI-раздела создать каталог «loader», а в нём файл «loader.conf» с тремя строчками (привожу свои):
Параметр editor отвечает за возможность отредактировать пункт загрузочного меню перед запуском.
Рядом с loader.conf необходимо создать каталог entries — один файл в нём будет отвечать за одну загрузочную запись в boot-меню. У меня там один файл arch.conf с таким содержанием:
Я не упомянул, но довольно очевидно — ядро и initramfs должны лежать в одной файловой системе с загрузчиком, то есть на EFI-разделе. Пути к ним в конфигах отсчитываются от корня этой ФС.
Другие загрузчики
systemd-boot очень простой и предоставляет спартанского вида чёрно-белое меню. Есть варианты красивей, если душа просит красоты.
rEFind — очень красивый загрузчик. Скачать можно тут в виде deb-пакета. Использую на своём ноуте. Умеет создавать загрузочное меню автоматически, без конфига — просто сканируя файлы.
Clover. Позволяет выставлять нативное разрешение экрана, имеет поддержку мыши на экране загрузки, разные темы оформления. Дефолтная тема ужасна, конфиг в виде xml нечитаем, настроить не смог.
Различные неочевидные последствия
Вы можете легко попробовать эту схему в работе. Берёте USB-флешку, форматируете в таблицу разделов GPT, создаете FAT-раздел и копируете туда загрузчик. Комп сможет с неё стартовать.
Если просто скопировать на такую флешку boot-раздел установленного linux — система будет спокойно загружаться с флешки, не видя разницы.
Слегка ржавое EFI-приложение
После двух твитов, оставленных на прошлой неделе, про мои игры с UEFI и Rust, несколько человек попросили опубликовать заметку, объясняющую как создать UEFI-приложение, полностью написанное на Расте и продемонстрировать тестовое окружение.
Так что сегодняшняя цель — это создание UEFI-приложения на Расте, которое распечатывает карту памяти, отфильтрованную по доступности для использования (такая память называется традиционной памятью в описании UEFI-спецификаций):
Однако прежде, чем приступить к работе, освежим некоторые понятия.
▍ Скомканное вступление
При включении компьютера аппаратная часть находится в неопределённом состоянии и необходимо выполнить некоторую инициализацию для того, чтобы подготовить систему к предстоящей работе. BIOS, акроним для Basic Input/Output System, появившийся в районе 1975 года и использовавшийся с тех пор, был способом проведения аппаратной инициализации во время процесса загрузки и предоставления сервисов времени выполнения для ОС и программ. Однако BIOS имеет некоторые ограничения и после 40 лет применения заменён на Unified Extensible Firmware Interface (или UEFI для краткости). UEFI нацелен на устранение технических недостатков BIOS.
UEFI — это спецификация, которая определяет программный интерфейс между ОС\UEFI-приложением и прошивкой платформы. Intel разработала изначальную Extensible Firmware Interface (EFI), работы над которой были закончены в июле 2005 года. В начале 2006 года Apple одной из первых внедрила технологию на своих Intel Macintosh. В том же самом 2005 году выход UEFI сделал устаревшим EFI 1.10 — последний выпуск EFI. UEFI форум — это индустриальный орган, который управляет UEFI-спецификациями. Интерфейс, определяемый этими спецификациями, включает таблицы данных, которые содержат информацию о платформе, сервисы времени загрузки и выполнения, которые доступны приложению\загрузчику ОС. Такая прошивка имеет ряд преимуществ перед традиционным BIOS:
▍ Окисление — это хорошо
Как говорилось в начале, Раст будет использован для написания UEFI-приложения. Для тех, кто не знает, что это такое: Раст — системный язык программирования, разработку которого спонсирует Mozilla. Она описывает его как «безопасный, конкурентный, практичный язык», поддерживающий функциональную и императивно-процедурную парадигмы. Язык очень похож на Си++ в плане синтаксиса, но создатели Раста намереваются обеспечить в нём лучшую безопасность по памяти при сохранении производительности.
ЯП явился результатом персонального проекта сотрудника Mozilla Грейдона Хоара. Организация стала поддерживать проект в 2009 году, после осознания его потенциала. В 2010 году было публично объявлено о проекте; в том же самом году компилятор, изначально разработанный на OCaml, начали переписывать на Расте с использованием LLVM-backend.
Первая пре-альфа версия компилятора появилась в январе 2012 года, но уже через 3 года, 15 мая 2015 была выпущена первая стабильная версия (теперь известная как редакция 2015). Раст является проектом с открытым сообществом. Такая модель означает, что любой может вкладываться в разработку и в уточнение языка, и этот вклад может быть разным, например, улучшение документации, отправка баг-репортов, предложения RFC на добавление функциональности или изменения программного кода. Язык получил огромную обратную связь по опыту разработки Серво — современного движка для обозревателей с превосходной производительностью и возможностью встроенного применения. В наши дни Раст начинает присутствовать во всех сферах ПО, к примеру, в ПО для управления спутниками, программировании микроконтроллеров, веб-серверов, в обозревателе Firefox и т.д. Раст выигрывал первое место в номинации «наиболее любимый язык программирования» в опросе Stack Overflow Developer в 2016, 2017 и 2018 годах (прим. переводчика — и в 2021).
▍ Ещё два или три момента перед началом
Для того чтобы написать загрузчик, гипервизор или низкоуровневое приложение требуется использовать системный язык программирования. Есть отличная статья с подробным обсуждением этого понятия. Проще говоря, системный ЯП — это язык, позволяющий тонкий контроль над исполнением кода в машине и возможностью изменения любых отдельных байтов в памяти компьютера. И с Растом это возможно.
Наконец, для тестового окружения будут использованы Питон и QEMU вкупе с OVMF. QEMU — это хорошо известный полносистемный эмулятор, позволяющий запускать код для любой машины на любой поддерживаемой архитектуре. OVMF — это основанный на EDK II проект, предоставляющий поддержку UEFI для виртуальных машин (QEMU и KVM). QEMU не содержит в поставке OVMF, так что придётся установить его отдельно на вашу машину, либо взять предсобранные образы из Сети.
Например, такие доступны для загрузки в моём тестовом хранилище.
▍ Начинаем
Без дальнейших промедлений приступаем к работе! Первым делом создадим папку и инициализируем Раст проект в ней:
Теперь добавим uefi-rs в качестве зависимости. Чтобы сделать это, просто добавьте следующие строки в ваш Cargo.toml:
▍ Рабочий процесс сборки\запуска
И затем добавим крейт в качестве зависимости, чтобы mem* функции были связаны:
Далее создадим файл x86_64-none-efi.json со следующим содержимым:
По правде говоря, на текущий момент уже нет необходимости в создании такого файла. Поддержку uefi влили — PR/56769.
Я решил всё же переводить статью в оригинальном виде.
Вообще, сейчас полезно сразу читать uefi-rs/BUILDING.md.
Исполняемый UEFI-файл не что иное, как двоичный формат PE, используемый Windows, но со специальной подсистемой и без таблицы символов; поэтому целевое семейство установлено как windows.
Сейчас нужно создать build.py, реализующий две команды:
Заметка: я не нашёл, по какой причине исполняемый файл не загружается автоматически с этой версией OVMF, поэтому используется сценарий startup.nsh для облегчения загрузки.
▍ Само приложение
Первым шагом нужно заставить грузиться приложение и войти в бесконечный цикл, предупреждая выход в прошивку.
В Расте ошибки могут быть доведены до паники или аварийного прекращения. Паника случается, когда что-то идёт не так, но в целом можно продолжить работу (такое обычно случается с потоками); аварийное завершение происходит, когда программа переходит в состояние, из которого невозможно восстановление. Наличие обработчика паники обязательно, он реализуется в стандартной библиотеке; но поскольку приложение не зависит от ОС, то и стд не может быть использована. Вместо этого мы используем core часть библиотеки, в которой обработчик отсутствует, так что мы вынуждены реализовывать его самостоятельно. К счастью, uefi-rs предоставляет одну реализацию оного.
Первые две строки обозначают, что наш крейт не имеет функции main и не зависит от стд. Также точка входа помечена аттрибутом entry.
Наконец, после сборки и запуска приложения, QEMU отобразит что-то похожее на картину ниже:
QEMU исполняет UEFI-приложение
Ничего интересного, но т.к. QEMU не перешла в цикл загрузки или выскочила в EFI-оболочку, убеждаемся, что наше приложение вызвано. Следующий шаг заключается в том, чтобы напечатать версию UEFI на экран. Опять же, в rust-rs уже реализованы вспомогательные функции для этого, поэтому достаточно проинициализировать систему логгирования и использовать макрос info! для распечатки текста на экране или даже на последовательном порту.
Для доступа к макросу info! нужно добавить новую зависимость в Cargo.toml:
Затем необходимо просто добавить следующий код в главную функцию, перед входом в бесконечный цикл:
После сборки и запуска приложение выведет что-то вроде INFO: UEFI 2.70. Эта информация зависит от версии прошивки, которую вы используете.
В завершение давайте напишем функцию, которая принимает ссылку на таблицу Boot Services и распечатывает регионы свободной для использования памяти. Сперва нам потребуется включить крейт alloc, чтобы получить доступ к структуре Vec; для этого нужно добавить следующие три строки в начало файла:
После этого определим константу с размером EFI-страницы, который равен 4KiB независимо от системы.
И, собственно, реализуем непосредственно функцию по обходу карты в поисках традиционной памяти и распечатке свободных диапазонов на экран:
Конечный результат должен совпадать с выводом, изображённым на КДПВ.
И готово! было несложно, правда? Теперь вы можете продолжить реализовывать новые возможности в приложении, вероятно решившись разрабатывать загрузчик или более сложное UEFI приложение.
И ещё одна важная ремарка для отважных духом. Если вы пустились в разработку своей собственной ОС или углубились в изучение технологии, то вы должны отложить в сторону все API, предоставляемые UEFI для взаимодействия с файловой системой, сетью, доступом к PCI-устройствам и т.д., и разработать свои собственные драйвера.
Не ленитесь от использования всех этих предоставленных абстракций!
Active Restore: С чего начать разработку в UEFI
Всем привет. В рамках проекта от компании Acronis со студентами Университета Иннополис (подробнее о проекте мы уже описали это тут и тут) мы изучали последовательность загрузки операционной системы Windows. Появилась идея исполнять логику даже до загрузки самой ОС. Следовательно, мы попробовали написать что-нибудь для общего развития, для плавного погружения в UEFI. В этой статье мы пройдем по теории и попрактикуемся с чтением и записью на диск в pre-OS среде.
В компании Acronis команд, которые занимаются UEFI, не так много, поэтому я решил разобраться в вопросе самостоятельно. К тому же есть проверенный способ получить огромное количество точных советов совершенно бесплатно и свободно — просто начать делать что-либо и выложить это в интернет. Поэтому комментарии и рекомендации под этим постом очень приветствуются! Вторая цель данного поста собрать небольшой дайджест статей о UEFI и помочь двигаться в этом направлении.
Полезные ссылки
Для начала хочу перечислить список источников, которые мне очень помогли. Возможно вам они тоже помогут и ответят на ваши вопросы.
Немного теории
Хочу напомнить требования и цели проекта Active Restore. Мы планируем приоритизировать файлы в системе для более эффективного восстановления. Для этого нужно запуститься на максимально раннем этапе загрузки ОС. Для понимания наших возможностей в мире UEFI стоит немного углубиться в теорию о том как проходит цикл загрузки. Информация для этой части полностью взята из этого источника, который я постараюсь популярно пересказать.
UEFI или Unified Extensible Firmware Interface стал эволюцией Legacy BIOS. В модели UEFI тоже есть базовая система ввода-вывода для взаимодействия с железом, хотя процесс загрузки системы и стал отличаться. UEFI использует GPT (Guid partition table). GPT тесно связана со спецификацией и является более продвинутой моделью для хранения информации о разделах диска. Изменился процесс, но задачи остались прежними: инициализация устройств ввода-вывода и передача управления в код операционной системы. UEFI не только заменяет бóльшую часть функций BIOS, но также предоставляет широкий спектр возможности для разработки в pre-OS среде. Хорошее сравнение Legacy BIOS и UEFI есть тут.
В данном представлении BIOS это компонент, обеспечивающий непосредственное общение с железом и является firmware. UEFI это унификация интерфейса железа для операционной системы, что существенно облегчает жизнь разработчикам.
В мире UEFI мы можем разрабатывать драйвера или приложения. Есть специальный подтип приложений — загрузчики. Разница лишь в том, что эти приложения не завершаются привычным нам образом. Завершаются они вызовом функции ExitBootServices() и передают управление в операционную систему. Чтобы принять решение какой же драйвер нужен вам, рекомендую заглянуть сюда, чтобы расширить понимание о протоколах и рекомендациях по их использованию.
Dev kits
Небольшой список того, что мы будем использовать в нашей практике:
Последовательность загрузки
Коротко разберем через какие стадии проходит наша машина, прежде чем мы видим заветный логотип операционной системы. Для этого рассмотрим следующую диаграмму:
Ссылка
Процесс с момента нажатия на кнопку питания на корпусе и до полной готовности UEFI интерфейса называется Platform Initialization и делится он на несколько фаз:
Ссылка
Классный рассказ о этапах загрузки есть тут.
Подготовка проекта
Пришло время поставить перед собой простую задачу. Мы можем загрузить наш драйвер в DXE фазе, открыть файл на диске и записать в него какие — нибудь данные. Задача достаточно простая, чтобы потренироваться.
Как я уже упоминал мы воспользуемся проектом VisualUEFI, однако рекомендую также попробовать способы описанные тут, хотя бы потому, что использовать дебагер легче в описанном по ссылке способе.
Допускаю, что у вас уже есть Visual Studio. В моем случае у меня Visual Studio 2019. Для начала клонируем себе проект VisualUEFI:
Нам понадобится NASM (https://www.nasm.us/pub/nasm/releasebuilds/2.15.02/win64/). Переходим и скачиваем. На момент написания статьи актуальной версией является 2.15.02. После установки убедитесь, что в переменных средах у вас есть NASM_PREFIX, который указывает на папку, в которую был установлен NASM. В моем случае это C:\Program Files\NASM\.
Соберем EDKII. Для этого открываем EDK-II.sln из \VisualUefi\EDK-II, и просто жмем build на решении. Все проекты в решении должны успешно собраться, и можно переходить к уже готовым примерам. Открываем samples.sln из \VisualUefi\samples. Жмем build на приложении и драйвере, после чего можно запускать QEMU простым нажатием F5.
Проверяем наш UefiDriver и UefiApplication, именно так называются примеры в решении samples.sln.
Отлично, драйвер не только собрался, но и успешно загрузился. Выполнив команду drivers, мы даже увидим его в списке.
Если бы в коде мы не возвращали EFI_ACCESS_DENIED в функции UefiUnload, мы бы даже смогли выгрузить наш драйвер, выполнив команду:
Теперь вызовем наше приложение:
Написание кода
Рассмотрим код предоставленного нам драйвера. Все начинается с функции UefiMain, которая находится в файле drvmain.c. Мы бы могли назвать точку входа и другим именем, если бы писали драйвер “с нуля”, указать это можно было бы в .inf файле.
В проекте от нас не требуют регистрировать Unload функцию, так как VisualUEFI это и так уже делает “под капотом”, нужно просто её объявить. В примере она в этом же файле и называется UefiUnload. В этой функции мы можем написать код, который освободит все занятые нами ресурсы, так как она будет вызвана при выгрузке драйвера. Регистрация Unload функции в проекте VisualUEFI происходит в файле DriverEntryPoint.c, в функции _ModuleEntryPoint.
В нашем примере, в функции UefiMain, происходит вызов функции EfiLibInstallDriverBindingComponentName2, которая регистрирует имя нашего драйвера и Driver Binding Protocol. Согласно модели драйверов UEFI, все драйвера устройств должны регистрировать этот протокол для предоставления контроллеру функций Support, Start, Stop. Функция Support отвечает, может ли наш драйвер работать с данным контроллером. Если да, то вызывается функция Start. Подробнее об этом хорошо описано в спецификации (раздел Protocols — UEFI Driver Model). В нашем примере функции Support, Start и Stop устанавливают наш кастомный протокол. Его реализация в файле drvpnp.c:
Фукнция EfiLibInstallDriverBindingComponentName2 реализована в файле UefiDriverModel.c, и, на самом деле, очень простая. Она вызывает InstallMultipleProtocolInterfaces из Boot Services (см. Спецификацию стр 210). Данная функция связывает handle (в нашем случае ImageHandle, который мы получили на точке входа) и протокол.
Как вы могли заметить, в нашем коде мы взаимодействуем с UEFI через глобальное поле gBS (global Boot Services). Также, существует gRT (global Runtime Services), а вместе они являются частью структуры System Table. Источник.
Для работы с файлами нам понадобится Simple File System Protocol (см. Спецификацию стр 504). Вызвав функцию LocateProtocol, можно получить на него указатель, хотя более правильный способ перечислить все handles на устройства файловой системы с помощью функции LocateHandleBuffer, и, перебрав все протоколы Simple File System, выбрать подходящий, который позволит нам писать и читать в файл. Пример такого кода тут. А мы же воспользуемся способом проще. У протокола есть всего одна функция, которая позволит нам открыть том.
Далее, нам необходимо уметь создавать файл и закрывать его. Воспользуемся EFI_FILE_PROTOCOL, в котором есть функции для работы с файловой системой (см. Спецификацию стр 506).
Для записи в файл нам придется вручную двигать каретку. Для этого будем спрашивать размер файла с помощью функции GetInfo.
Вызываем наши функции и пишем случайные данные в наш файл:
Есть альтернативный способ выполнить нашу задачу. В проекте VisualUEFI уже реализовано то, что мы написали выше. Мы можем просто подключить заголовочный файл ShellLib.h и вызвать в самом начале функцию ShellInitialize. Все необходимые протоколы для работы с файловой системой будут открыты, а функции ShellOpenFileByName, ShellWrite и ShellRead реализованы почти так же, как и у нас.
→ Код этого примера на github
Если мы хотим перейти в VMWare, то наиболее правильным будет модификация firmware с помощью UEFITool. Например тут демонстрируется как добавляют NTFS драйвер в UEFI.
Выводы
Усложнить идею нашего драйвера и ближе подвести его под требования проекта Active Restore можно следующим образом: открыть протокол BLOCK_IO, заменить функции чтения на диск нашими функциями, которые запишут данные, читаемые с диска в лог и затем вызовут оригинальные функции. Сделать это можно следующим образом:
Нужно будет не забыть подписаться на ExitBootServices(), чтобы вернуть указатели на место. После того, как фильтр файловой системы в Windows будет готов, минифильтр продолжит логировать чтение с диска.
Но это это уже идеи для будущих статей. Спасибо за внимание.