Структура EFI

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

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

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

Определить капсулу просто – в самом её начале будет (самые первые 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-ки, то и механизмы их обработки/подгрузки/защиты – схожие. Но это уже совсем другая история…