Структура упаковки EFI отличается от "классической", что обязательно нужно учитывать, чтобы разобраться в общей схеме его (таки EFI - это "ифай", а не "ефи", потому причислим оного к мужскому роду :) ) работы. В классической схеме "старого" BIOS для каждого модуля имеется "заранее" прописанное место назначения/распаковки, которое или берётся из его заголовка напрямую, либо определяется его ID. В EFI же модули не имеют подобной привязки и за их распаковку/загрузку/расположение в памяти отвечает соответствующий менеджер, действуя, так сказать, "по собственному усмотрению".

Важным отличием, которое обычно сразу бросается в глаза – «неровный» объём файла EFI-образа. Хотя, понятно, в микросхему он зашивается «ровным». Если так – значит у вас не образ для прошивки, а «капсула», в которой имеются уже нужные модули. Т.е. EFI, в отличие от BIOS может быть представлен в двух вариантах – в качестве «обычного» образа для прошивки (с «кратным» объёмом) и в качестве «капсулы», имеющей «неровный» объём, обычно чуть более мегабайта (но не обязательно – может быть 4Мб и больше).

[off]/* Начну по-порядку, далее, после, поредактирую. */[/off]

Определить капсулу просто – в самом её начале будет (самые первые 16 байт):
BD 86 66 3B 76 0D 30 40 B7 0E B5 51 9E 2F C5 A0

Это её (капсулы) GUID, уникальный 16-байтный идентификатор, который имеют все структуры (т.е. не только модули, но и любые упорядоченные нужные данные) в EFI.

Саму структуру капсулы можно найти в исходниках:
typedef struct { EFI_GUID CapsuleGuid; UINT32 HeaderSize; UINT32 Flags; UINT32 CapsuleImageSize; UINT32 SequenceNumber; EFI_GUID InstanceId; UINT32 OffsetToSplitInformation; UINT32 OffsetToCapsuleBody; UINT32 OffsetToOemDefinedHeader; UINT32 OffsetToAuthorInformation; UINT32 OffsetToRevisionInformation; UINT32 OffsetToShortDescription; UINT32 OffsetToLongDescription; UINT32 OffsetToApplicableDevices; } EFI_CAPSULE_HEADER;

К сожалению, здесь и дальше «навсегда», тем, кто захочет «плотно» разобраться с темой EFI нужно учесть, что расхожее мнение, что «там всё есть» - в плане Open Sources (конкретно для EFI – tianocore.org, uefi.org) ничего хорошего не обозначает, кроме того, что в переводе на русский – там можно найти «полуфабрикат» и его нужно будет, во-первых, правильно готовить, во-вторых, на вкус и цвет товарища нет. Последнее утверждение выливается в то, что некоторые как бы «стандартные» (т.е. вроде бы «стандартизированные») вещи некоторые «отдельно взятые» BIOS-писатели – трактуют «немножко по-своему».
Кроме того, это нужно помножить на эволюцию EFI от 1.0/1.1 до EFI/UEFI2.1b на данный момент. При том, некоторые вещи принципиально поменялись при переходе на вторую версию, однако были оставлены возможности для поддержки (т.е. есть в исходниках) сразу обоих, что выливается в двойное трактование некоторых структур (т.к. для старых версий они были одного вида, а в современных – другого). Так и EFI-образы, с которыми вы столкнётесь могут относится к разным версиям.
Применительно к нашему самому первому случаю та же структура EFI-капсулы в девичестве была другой. Однако, чтобы вас лишний не путать, я здесь и дальше буду указывать лишь «правильные» версии структур, обычно это последние версии (не всегда, т.к. несмотря на наличие и поддержку новых спецификаций никто не запрещает пользоваться BIOS-писателям старым проверенным кодом).



Итак, продолжу интервью самого с собой. Как я писал в последний раз, важно понимать, что не всё ещё сложилось в датском королевстве. Но таки сложилось, чай уж скоро десяток лет как складывается. Итак, вернёмся к нашим тараканам.

Капсула – как матрёшка. В ней есть другие матрёшки, которые могут содержать внутри себя ещё матрёшки и так далее. В этом есть важное отличие – в стареньком BIOS подобной «рекурсии» не наблюдается.

FFS (Firmware File System) – есть «чисто» матрёшка, которая позволяет помечать нужную часть собственной «биркой» (т.к. имеет свой GUID):
// // FFS file header definition // typedef UINT8 EFI_FFS_FILE_ATTRIBUTES; typedef UINT8 EFI_FFS_FILE_STATE; typedef struct { EFI_GUID Name; EFI_FFS_INTEGRITY_CHECK IntegrityCheck; EFI_FV_FILETYPE Type; EFI_FFS_FILE_ATTRIBUTES Attributes; UINT8 Size[3]; EFI_FFS_FILE_STATE State; } EFI_FFS_FILE_HEADER;

FFS или дальше просто «файл» в нашей системе – есть «обёртка» для FV – Firmware Volume. А вот именно FV уже являются важнейшими для нас матрёшками, внутри них содержится «логически законченный» набор блоков/модулей. К примеру, PreEFI (аналог BootBlock для BIOS). Или FV ядра, где содержатся модули основной стадии (аналог POST для BIOS), который, кстати, может содержать сотни вложенных файлов-модулей.


Структура «раздела» (FV):
// // Firmware Volume Header definition // typedef struct { UINT8 ZeroVector[16]; EFI_GUID FileSystemGuid; UINT64 FvLength; UINT32 Signature; EFI_FVB_ATTRIBUTES Attributes; UINT16 HeaderLength; UINT16 Checksum; #if (PI_SPECIFICATION_VERSION < 0x00010000) UINT8 Reserved[3]; #else UINT16 ExtHeaderOffset; UINT8 Reserved[1]; #endif UINT8 Revision; EFI_FV_BLOCK_MAP_ENTRY FvBlockMap[1]; } EFI_FIRMWARE_VOLUME_HEADER;
В ней как раз уже можно заметить упомянутую совместимость с предыдущими версиями. В данном случае это не принципиально, т.к. всё очевидно и не оно влияет на длину, однако так не всегда.

На этом вложенность не заканчивается, я бы даже сказал – только начинается , т.к. FV – тоже, в принципе, можно обозвать лишь «обёрткой». Внутри разделов располагаются секции, которые бывают разные, потому имеют разные заголовки, но неизменяемая их начальная часть имеет следующий вид:
// // Common section header // typedef struct { UINT8 Size[3]; UINT8; } EFI_COMMON_SECTION_HEADER;

Как можно догадаться байт типа (Type) определяет, что это за секция и какие внутри неё будут данные. Внутри секций уже снова могут располагаться файлы, разделы, снова секции (вложенные в предыдущие «матрёшки» и т.д. Подобная вложенность может достигать десятого и более уровней…

Однако главной единицей информации является «модуль». Он содержится внутри секций (если нет вложений). Тип секции описывает тип вложенного в неё модуля, которые бывают разными (больше десятка видов), но наиболее распространёнными (точней – важными для нас) являются PE32-модули. Это, как видно из названия - PE32-файлы и по сути являются «нормальными» dll-ками лишь со слегка изменёнными заголовками. Данный факт сразу проливает много на всю суть EFI, которая имеет внутри себя по большому счёту набор «почти виндовых» dll-ок. А раз это dll-ки, то и механизмы их обработки/подгрузки/защиты – схожие. Но это уже совсем другая история…