Создать собственный UEFI-загрузчик для серверной платформы на Intel Xeon IceLake без исходников, полной документации и официальной поддержки ― звучит как приключение. Мы в OpenYard решились на этот шаг, чтобы получить полный контроль над прошивкой, безопасность на уровне железа и независимость от вендоров. В статье наш путь: от первых проб с edk2 и FSP до релиза OYBoot, с реверсом драйверов, интеграцией BMC и борьбой за стабильный старт платформы.
Идея о разработке своего UEFI-загрузчика прорабатывалась достаточно стремительно. Во время обсуждений рассматривались все преимущества, недостатки, вопросы и потенциальные сложности этого мероприятия. В какой-то момент времени количество недостатков и вопросов примерно уравновесили преимущества.
Действительно, на разработку жизнеспособного загрузчика необходимо немало времени (ибо платформа Intel Xeon сложна), достаточно приличный штат разработчиков и доступ к необходимому набору документации от Intel (гайды, мануалы, описания регистров и т.д). Разумеется, ничего из перечисленного под рукой не оказалось, но был некоторый опыт в bring-up новых материнских плат, разработке UEFI-модулей и драйверов. А вот чего мы ждали: возможность контролировать функциональный состав прошивок, обеспечивать непрерывную и стабильную поддержку пользователей, гарантировать в полном объеме информационную безопасность наших аппаратных платформ. Ну и, конечно же, нельзя не упомянуть о престиже OpenYard, как разработчика и производителя серверной электроники.
Разумеется, в силу отсутствия проприетарных исходных кодов на актуальное на тот момент поколение Xeon Scalable (IceLake) единственным нашим инструментом стал edk2-framework. В качестве шаблона для проекта мы использовали также доступные opensource репозитории edk2-platforms и самый важный Intel-FSP, который предоставляет разработчикам бинарные образы FSP (Intel Firmware Support Package), являющиеся неотъемлемой частью Intel-based платформ (серверных, пользовательских, мобильных). И вот на этом этапе возник первый серьезный вопрос: как разобраться с настройками этого бинарного модуля, не имея в доступе полного набора документации от Intel, а тем более какой-либо технической поддержки. В распоряжении команды был только FSP2.0 Integration Guide и набор хедеров, приложенных в репозитории Intel-FSP для целевого процессора. Стоит отметить, что код хедера FSP сделан максимально читабельным и с неплохим набором пояснений и комментариев, что несколько компенсирует сложности в разработке без доступа к документации.
/** FSP-M Configuration
**/
typedef struct {
/** Offset 0x0040 - Customer Revision
The Customer can set this revision string for their own purpose.
**/
UINT8 CustomerRevision[32];
/** Offset 0x0060 - Bus Ratio
Indicates the ratio of Bus/MMIOL/IO resource to be allocated for each CPU's IIO.
Default 0x1
**/
UINT8 BusRatio[8];
/** Offset 0x0068 - D2K Credit Config
Set the D2K Credit Config. 1: Min,<b>2: Med (Default), 3: Max.
1:Min, 2:Med, 3:Max
**/
UINT8 D2KCreditConfig;
/** Offset 0x0069 - Snoop Throttle Config
Set the Snoop Throttle Config. <b>0: Disable(Default)</b>, 1: Min, 2: Med, 3: Max
0:Disable, 1:Min, 2:Med, 3:Max
**/
UINT8 SnoopThrottleConfig;
/** Offset 0x006A - Snoop Throttle Config
Set the Snoop All Core Config. <b>0: Disable(Default)</b>, 1: Enable, 2: Auto
0:Disable, 1:Enable, 2:Auto
**/
UINT8 SnoopAllCores;
/** Offset 0x006B - Legacy VGA Socket
Socket that claims the legacy VGA range. Default: Socket 0
**/
UINT8 LegacyVgaSoc;
/** Offset 0x006C - Legacy VGA Stack
Stack that claims the legacy VGA range. Default: Stack 0Первой важной задачей во всей этой истории была корректная и достаточная конфигурация и интеграция FSP в наш проект. Здесь стоит сказать, что мы пошли по самому простому алгоритму: внесение изменений в программный код конфигурации FSP, сборка нашего бинарного образа UEFI, запуск на целевой платформе и контроль состояния загрузки в отладочной консоли. По большому счету такой алгоритм называется «метод проб и ошибок». Количество итераций, которые мы провели для успешного перехода хотя бы в UEFI-payload назвать страшно. Наибольшее время мы затратили на поиск оптимальных настроек FSP для корректного исполнения MRC (Memory Reference Code). Результатом этого этапа стала загрузка нашей системы в оболочку Efi (Efi shell)… Но только в отладочной консоли. Как позже выяснилось, у нас не работала видеоконсоль в силу отсутствия в нашей сборке корректного Efi-драйвера.
С этого момента история приобрела иные краски. Закончился этап игры «в угадайку» и мы приступили к превращению полуфабриката в конечный продукт. К этому моменту у команды появилось больше понимания об особенностях целевой платформы, о поведении FSP, а также появилось больше уверенности в своих силах. Это позволило нам несколько распараллелить разработку.
В части доработки необходимых драйверов команде пришлось осваивать технологии реверс-инжиниринга. Далеко не для всех драйверов было желание (да и возможность разрабатывать код самим). Как пример UEFI GOP ― драйвер: команда вытащила этот драйвер из уже имеющейся прошивки от нашего ODM партнера. А для правильной интеграции полученного бинарника в нашу сборку мы разработали код по примеру, взятому из одного из старых проприетарных проектов.
Пока одна часть команды боролась с созданием минимального работоспособного загрузчика, вторая часть разрабатывала функциональные модули, такие как: функции управления портами USB, PCIe и SATA платформы, устройствами шифрования TPM2.0, модуль настройки порта менеджмента (BMC).
Все это необходимо было завернуть в привычный и user-friendly интерфейс, который пользователям более знаком, как Setup Utility. Получилось так:
Отдельно отмечу задачи, связанные с обязательным функционалом взаимодействия нашего OYBoot с BMC (Baseboard Management Controller) по интерфейсу IPMI, а также трансляции полной SMBIOS-таблицы с целью обеспечения инвенторики оборудования. Тут сложность оказалась в том, что SMBIOS опять же надо было передавать в «черный ящик» под названием AMI MegaRAC. На помощь нам пришел уже повышенный опыт реверс-инжиниринга. После непродолжительного исследования команда точно знала все о механизме транспортировки SMBIOS-таблицы в пространство памяти BMC, а также почти все о структуре разделов этой таблицы. Разумеется, помимо стандартных типов (информация о системе, процессорах и памяти) нам пришлось создавать OEM-разделы, со структурами, понятными MegaRAC.
EFI_STATUS
EFIAPI
GetSmbiosTable(VOID** SmbiosTableAddress, UINT32* SmbiosTableSize)
{
EFI_STATUS Status = EFI_NOT_FOUND;
//
// Get SMBIOS table from System Configure table
//
Status = EfiGetSystemConfigurationTable(&gEfiSmbiosTableGuid, (VOID**)&mSmbiosTable);
if ((mSmbiosTable != NULL) && (!EFI_ERROR(Status))) {
SmbiosTableAddress = (UINT8)(UINTN)(mSmbiosTable->TableAddress);
*SmbiosTableSize = (UINT32)mSmbiosTable->TableLength;
return EFI_SUCCESS;
}
//
// Get SMBIOS table 3 from System Configure table
//
Status = EfiGetSystemConfigurationTable(&gEfiSmbios3TableGuid, (VOID**)&mSmbios64BitTable);
if ((mSmbios64BitTable != NULL) && (!EFI_ERROR(Status))) {
SmbiosTableAddress = (UINT8)(UINTN)(mSmbios64BitTable->TableAddress);
*SmbiosTableSize = (UINT32)mSmbios64BitTable->TableMaximumSize;
return EFI_SUCCESS;
}
return Status;
}
VOID
EFIAPI
ReadyToBootNotify(
EFI_EVENT Event,
VOID* Context)
{
EFI_STATUS Status;
EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop;
VOID* SmbiosTableAddress = NULL;
UINT32 SmbiosTableSize = 0x00;
UINT8 Response[0x10];
UINT8 ResponseSize = 0x10;
Status = gBS->LocateProtocol(
&gEfiGraphicsOutputProtocolGuid,
NULL,
(VOID**)&Gop
);
if (EFI_ERROR(Status)) {
return;
}
VOID* Destination = (VOID*)(UINTN)Gop->Mode->FrameBufferBase;
Status = GetSmbiosTable(&SmbiosTableAddress, &SmbiosTableSize);
DEBUG((DEBUG_INFO, "GetSmbiosTable, Status = %r\n", Status));
if (!EFI_ERROR(Status))
{
DEBUG((DEBUG_INFO, "Address = 0x%p, Size = 0x%x bytes\n", SmbiosTableAddress, SmbiosTableSize));
CopyMem(Destination, SmbiosTableAddress, SmbiosTableSize);
}
else
{
return;
}
ZeroMem(Response, 0x10);
UINT8 IpmiCommandData1[] = IPMI_COMMAND_DATA_GET_SHARED_MEMORY_ADDRESS;
Status = IpmiSendCommand(
IPMI_COMMAND_GET_SHARED_MEMORY_ADDRESS,
IpmiCommandData1,
sizeof(IpmiCommandData1),
Response,
&ResponseSize
);
DEBUG((DEBUG_INFO, "IpmiSendCommand: Get shared memory address, Status = %r\n", Status));
if (!EFI_ERROR(Status))
{
ZeroMem(Response, 0x10);
ResponseSize = 0x0A;
UINT8 IpmiCommandData2[] = IPMI_COMMAND_DATA_DATA_READY;
Status = IpmiSendCommand(
IPMI_COMMAND_DATA_READY,
IpmiCommandData2,
sizeof(IpmiCommandData2),
Response,
&ResponseSize
);
DEBUG((DEBUG_INFO, "IpmiSendCommand: Smbios data ready, Status = %r\n", Status));
}
gBS->Stall(1 1000 1000);
}Исходный код выше реализует разработанную нами процедуру автоматического определения адреса в пространстве памяти BMC для последующей передачи SMBIOS.
Полгода назад у нас не было ничего, кроме идеи, опыта bring-up и пары утилит с открытым кодом. Сегодня у нас есть OYBoot ― собственный UEFI-загрузчик, полностью адаптированный под наши серверы на Xeon IceLake, с поддержкой всех необходимых функций и глубокой интеграцией в инфраструктуру. Но ещё важнее ― мы получили бесценный опыт работы с FSP, освоили тонкости edk2, научились реверсить драйверы и наладили командную работу в условиях ограниченных ресурсов. Для нас это доказательство того, что даже в мире закрытых платформ можно добиться полного контроля над железом ― если есть упорство, любопытство и готовность к экспериментам.
