Разработка системы контроля целостности аппаратного оборудования в среде UEFI-BIOS

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Разработка системы контроля целостности аппаратного оборудования в среде UEFI-BIOS

А.А. Артамонова, А.В. Куров

А.А. Артамонова Московский государственный технический университет им. Н.Э. Баумана, Москва, Россия. А.В. Куров Московский государственный технический университет им. Н.Э. Баумана, Москва, Россия.

Аннотация. Разработка и производство компьютерных систем и компьютерного оборудования тесно связаны с вопросами обеспечения информационной безопасности и защиты данных. Одним из направлений в этой сфере является вопрос контроля целостности аппаратного оборудования для обнаружения и предотвращения добавления, удаления или замены устройств. Большинство существующих систем, решающих эту задачу, имеет ряд ограничений, среди которых может быть необходимость запуска под управлением операционной системы, наличие определенной версии BIOS или необходимость подключения специальных аппаратных компонентов. В статье предлагается метод, основная идея которого заключается в разработке UEFI-приложения, выполняющегося каждый раз при старте платформы до загрузки операционной системы, при первом запуске считывающего текущую конфигурацию устройств с помощью таблицы SMBIOS и низкоуровневых протоколов и сохраняющего ее в энергонезависимую память компьютера, а при последующих запусках сравнивающего текущую аппаратную конфигурацию с эталонной. В качестве аппаратной конфигурации для контроля предлагается использовать информацию об установленных процессорах, оперативной памяти, PCI-устройствах и жестких дисках. Такое приложение не будет зависеть от используемой версии BIOS, наличия операционной системы или определенной ее версии и не будет требовать наличия дополнительных аппаратных устройств.

Ключевые слова: UEFI, UEFI-приложение, SMBIOS, аппаратное обеспечение, контроль целостности

Development of a hardware integrity monitoring system in the UEFI-BlOS environment. Aleksandra A. Artamonova Bauman Moscow State Technical University, Moscow, Russia. Andrei V. Kurov, Bauman Moscow State Technical University, Moscow, Russia

Abstract. The development and production of the computer systems and computer equipment are closely related to the issues of information security and data protection. One of the directions in that area is the issue of monitoring the hardware integrity to detect and prevent the addition, removal or replacement of devices. Most existing systems that solve the problem have a number of limitations, including the need to run under an operating system, the presence of a specific BIOS version, or the need to connect special hardware components. The article proposes a method, the main idea of which is to develop a UEFI application that runs every time the computer starts before loading the operating system. While the first start it performs reading of current device configuration using the SMBIOS table and low-level protocols and stores it in the non-volatile memory of the computer. On subsequent runs it compares the current hardware configuration with the saved one and detects differences. As a hardware configuration for integrity monitoring it is suggested to use information about installed CPUs, RAM devices, PCI devices and hard drives. Such an application does not depend on the BIOS version used, the operating system or a specific version of it, and does not require additional hardware devices.

Keywords: UEFI, UEFI-Application, SMBIOS, hardware, hardware integrity

Введение

Разработка и производство компьютерных систем и компьютерного оборудования тесно связаны с вопросами обеспечения информационной безопасности и защиты данных. Решение этих задач обычно является комплексным и может включать в себя рассмотрение целого ряда проблем, среди которых присутствуют защита конфиденциальной информации от несанкционированного доступа, защита от мошеннических атак, защита интеллектуальной собственности от пиратства и т. д. Одним из направлений решения поставленной задачи является контроль состава аппаратного оборудования, который можно рассматривать по-разному в зависимости от требуемой сферы применения и необходимой степени защиты.

Сфера информационной безопасности успешно развивается, и по мере ее эволюции предлагаются различные подходы для надежного решения поставленных задач. Однако существует целый ряд ситуаций, в которых высокий уровень защиты не является обязательным, но может быть достигнут зачастую только использованием сложного и/или дорогостоящего решения. В качестве примера, когда необходим контроль аппаратного оборудования но использования сложной системы защиты не требуется, можно привести производство компьютерных систем с предоставлением гарантийного обслуживания. Заказчик оборудования при нарушении порядка использования оборудования и неудачной попытке обхода установленных производителем средств защиты интеллектуальной собственности должен нести ответственность в правовом поле, поэтому ясно, что использование дорогостоящих высокотехнологичных средств защиты информации в подобной ситуации является избыточным, а более простое решение, пусть и не такое надежное, оказывается более предпочтительным. Другим примером является обнаружение и предотвращение попыток хищения аппаратных компонент на рабочем месте сотрудниками компаний: вероятная выгода, которую злоумышленник сможет извлечь с учетом всех рисков, вряд ли будет выше, чем затраты на обход установленных средств защиты, даже если они не будут отвечать высоким стандартам безопасности.

В качестве минимального требования к системе безопасности, обладающей указанными особенностями, можно выделить наличие возможности определения целостности аппаратных компонент с целью обнаружения их добавления или изъятия. В этом случае существующие решения, удовлетворяющие поставленному требованию, можно условно разделить на три группы: программные высокого уровня, программные низкого уровня и программноаппаратные (с программной логикой низкого уровня).

Решения, принадлежащие к первой категории (например, Secret Net Studio Secret Net Studio [Электронный ресурс]. URL: https://www. securitycode.ru/products/secret-net-studio (дата обращения 10 декабря 2020).), отличаются тем, что доступ к их функциям может осуществляться только из операционной системы. К явным преимуществам таких систем можно отнести то, что разработка собственной системы этого уровня при необходимости не будет представлять особой сложности (если использование существующих решений по каким-либо причинам будет неприемлемо). Однако данный подход накладывает ряд ограничений, в частности, необходимость использования конкретной операционной системы (и в принципе использование любой операционной системы), из-за чего такие решения не отличаются универсальностью. Кроме того, это означает, что администратор или компания-производитель должны отвечать за установку этой операционной системы и последующую конфигурацию программных средств защиты.

Другой подход, включающий в себя использование низкоуровневых программных систем защиты, решает проблему зависимости от наличия операционной системы. К таким системам можно отнести многие из версий BIOS, в которые уже встроен подобный функционал (например, AMI BIOS BIOS/UEFI Firmware [Электронный ресурс]. URL: https://ami. com/en/products (дата обращения 10 декабря 2020).). В таких версиях BIOS можно настроить вывод предупреждений о замене аппаратных компонент и даже блокировку загрузки операционной системы в данном случае, а некоторые из них поддерживают также датчики вскрытия корпуса компьютера. К недостаткам данного подхода можно отнести зависимость от конкретной версии BIOS, и, следовательно, зависимость от производителя материнской платы, а также отсутствие гибкости настройки поведения в случае обнаружения несанкционированного доступа. Существуют и другие решения (например, ViPNet SafeBoot ViPNet SafeBoot [Электронный ресурс]. URL: https://infotecs.ru/ product/vipnet-safeboot.html (дата обращения 10 декабря 2020).), независимые от BIOS, однако они являются коммерческими, и алгоритмы их работы нельзя найти в открытом доступе.

Аппаратно-программные средства защиты (например, средство доверенной загрузки Dallas Lock СДЗ Dallas Lock [Электронный ресурс]. URL: https://dallaslock.ru/ products/sdz-dallas-lock (дата обращения 10 декабря 2020).) не зависят ни от операционной системы, ни от платформы, ни от версии BIOS. Такие системы включают в себя аппаратную часть (как правило, плату расширения с собственной энергонезависимой памятью) и программную, которая реализует функционал, контролирующий текущее состояние аппаратной конфигурации системы. К очевидным недостаткам таких систем можно отнести необходимость подключения дополнительных аппаратных компонентов, что может привести к невозможности использования таких систем на некоторых платформах (например, на ноутбуках).

В данной статье предлагается низкоуровневое программное решение для контроля целостности аппаратных компонент, которое не зависит от наличия операционной системы, конкретной версии BIOS и не требует подключения дополнительных аппаратных компонент. Основная идея предлагаемого метода заключается в разработке UEFI-приложения, которое встраивается в микросхему BIOS и хранит свои настройки в энергонезависимой памяти компьютера. При первом запуске компьютера UEFI-приложение считывает с помощью таблиц SMBIOS и низкоуровневых протоколов текущую аппаратную конфигурацию системы и сохраняет ее в качестве эталонной, а при последующих - сравнивает текущую конфигурацию с сохраненной и в случае обнаружения несоответствий выводит предупреждение. В качестве аппаратной конфигурации для сравнения предлагается использовать информацию об установленных процессорах, оперативной памяти, PCI-устройствах и жестких дисках.

Программная реализация системы

- UEFI-образ - это формат исполняемого содержимого, с помощью которого развертывается программный код. Все UEFI- образы содержат заголовок PE/COFF (Portable Executable Common Object File Format), который определяет формат исполняемого кода в соответствии со спецификацией [Microsoft 2020]. Целевым объектом этого кода может быть процессор IA-32, процессор Itanium®, x64, ARM или процессор с поддержкой EFI Byte Code (EBC). Заголовок определяет тип процессора и тип образа. В настоящий момент существует три типа UEFl-образов [Zimmer, Rothman, Marisetty 2010]:

- I-приложения (англ. UEFI applications) - образы, память и состояние которых очищаются (сбрасываются) при завершении;

- I-драйверы периода загрузки (англ. UEFI Boot Service drivers) - образы, память и состояние которых сохраняются на протяжении всего времени работы предварительной загрузки операционной системы. Их память очищается при вызове загрузчиком операционной системы функции ExitBootServicesQ;

UEFI-драйверы периода выполнения (англ. UEFI Runtime drivers) - образы, память и состояние которых сохраняются на протяжении всего времени работы машины. Эти образы работают совместно с операционной системой, поддерживающей UEFI.

Кроме того, доступно несколько поддерживаемых мест хранения UEFI-образов, в их числе:

- ПЗУ (ROM) на PCI-карте;

- системное ПЗУ или системная флеш-память;

- мультимедийное устройство (например, жесткий диск, дискета, DVD);

- загрузочный LAN-сервер.

Поскольку система проверки целостности аппаратной конфигурации должна запускаться непосредственно на целевом устройстве без использования каких-либо накопителей и не должна предоставлять доступ к своим данным для других UEFI-образов, в качестве типа образа используется UEFI-приложение, а в качестве расположения - Flash ROM-память, в которой находится образ BIOS. В качестве места для хранения своих настроек система использует NVRAM-память, энергонезависимую память компьютера.

Программный код UEFI-BIOS состоит из различных пакетов, которые, в свою очередь, являются логическим объединением определенного количества модулей - наименьших фрагментов отдельно компилируемого или предварительно созданного кода [Tianocore 2018b]. Каждый пакет имеет одинаковую структуру каталогов для разделения файлов исходного кода. Каждый пакет может включать в себя следующие корневые каталоги: Include, Library, Application, Drivers. Каталог Include содержит заголовочные файлы, предназначенные для использования другими пакетами. В каталоге Library находятся подкаталоги для каждого модуля библиотеки в составе пакета. Аналогичным образом каталог Application включает в себя подкаталоги для каждого модуля приложения, а Driver - подкаталоги для модулей драйверов. При использовании системы сборки EDKII в каталоге пакета также должны находиться DEC- файл декларации пакета и DSC-файл с инструкциями для сборки, а в подкаталоге каждого из модулей - INF-файл метаданных.

Структура пакета, реализующего систему проверки целостности аппаратной конфигурации, представлена на рис. 1.

Рис. 1. Структура пакета HardwareSafetyPkg

компьютерный программный код

Файл исходного кода HardwareSafety.c содержит основную точку входа в приложение, реализацию функций пользовательского интерфейса и функций для работы с NVRAM-памятью для чтения и записи конфигурации устройств, а также вызовы необходимых функций из библиотек устройств.

Библиотеки устройств отвечают за реализацию функционала для работы с каждым из четырех типов поддерживаемых аппаратных компонентов - процессоры (CpuDevicelnfoLib), оперативная память (RamDeviceInfoLib), PCI-устройства (PciDeviceInfoLib) и жесткие диски (HdDeviceInfoLib). Кроме того, для получения информации о процессорах и установленной оперативной памяти используется вспомогательная библиотека для удобной работы с таблицей SMBIOS (SmbiosUtilsLib). DSC-файл содержит информацию для систем сборки, а в DEC-файле и INF-файлах находится конфигурационная информация о пакете и модулях соответственно.

Способ получения информации об аппаратных компонентах отличается в зависимости от их типа, однако для удобства использования все библиотеки устройств построены по единому принципу. В заголовочных файлах (CpuDeviceInfoLib.h, RamDeviceInfoLib.h, PciDeviceInfoLib.h и HdDeviceInfoLib.h) находятся описания идентификационной информации об устройстве конкретного типа и общей конфигурации этих устройств, которая включает в себя их количество и массив с указателями на соответствующие структуры с информацией для идентификации. Кроме того, здесь располагаются прототипы двух функций, доступных вне библиотеки: получение текущего состояния конфигурации этих аппаратных компонентов и сравнение двух конфигураций данного типа. Реализации этих функций находятся, соответственно, в соответствующих файлах исходного кода (CpuDeviceInfoLibx, RamDeviceInfoLibx, PciDeviceInfoLibx и HdDeviceInfoLib.o).

Каждый тип устройств обладает своей спецификой получения данных о конфигурации. Для доступа к информации об установленных процессорах и оперативной памяти используется таблица SMBIOS. Таблица SMBIOS состоит из точки входа и переменного числа структур, описывающих компоненты и функции платформы, которые обычно называют таблицами или записями [DMTF 2020]. Информация в таблице обновляется каждый раз при запуске системы до запуска UEFI-образов [Unified Extensible Firmware 2019], что гарантирует актуальность считанной конфигурации устройств на стадии запуска UEFI-приложения. Реализации вспомогательных функций для чтения записей этой таблицы находятся в файле исходного кода SmbiosInfo.c.

Для каждого из процессоров в SMBIOS определена таблица типа EFI_SMBIOS_TYPE_PROCESSOR_INFORMATION, которая содержит специфичную для него информацию (тип, версия, производитель, серийный номер и т.д.). Для каждого из устройств оперативной памяти существует аналогичная таблица EFI_SMBIOS_TYPE_MEMORY_DEVICE. По причине того, что эта информация заполняется производителем и набор информационных полей может отличаться в зависимости от модели устройства, значения некоторых полей могут отсутствовать. Сравнение не одного поля (например, только серийного номера), а всей информации в совокупности делает проверку изменения конфигурации более надежной.

Список полей, составляющих идентификационную информацию для процессоров (структура CpuDevice) и оперативной памяти (структура RamDevice) вместе с примерами заполненного содержимого приведен в табл. 1 и табл. 2 соответственно. После получения информации об установленных устройствах остается только подсчитать их количество и сохранить необходимые данные в переменную конфигурации.

Таблица 1. Поля структуры, описывающей устройство типа CpuDevice

Таблица 2. Поля структуры, описывающей устройство типа RamDevice

В связи с тем что таблица SMBIOS предоставляет недостаточно информации для идентификации PCI-устройств и не содержит никаких данных об установленных жестких дисках, для получения этих конфигураций приложение использует внутренние протоколы UDKII UDK2018 [Электронный ресурс]. URL: https://github.com/tianocore/tianocore.github.io/wiki/UDK2018 (дата обращения 10 декабря 2020)., EFI_PCI_ROOT_BRIDGE_PROTOCOL и EFI_DISK_INFO_PROTOCOL соответственно. Во время инициализации UEFI происходит заполнение базы данных дескрипторов (англ. handle database), состоящей из дескрипторов и протоколов, с помощью которых регистрируются все вызываемые интерфейсы [Zimmer, Rothman, Marisetty 2010]; таким образом можно получить доступ к информации о соответствующих аппаратных компонентах. Интерфейсы, предоставляемые этими протоколами, скрывают специфические для платформы детали реализации и упрощают доступ к устройствам [Tianocore 2018a].

Информация об устройствах PCI и PCI-Express располагается в регистрах конфигурационного пространства PCI, доступ к которым осуществляется путем отправки команд конфигурации контроллеру PCI. Для этого сначала необходимо получить массив дескрипторов, поддерживающих протокол EFI_PCI_ROOT_BRIDGE_ PROTOCOL, при помощи функции gBS->LocateHandleBuffer(). Каждое из PCI-устройств обладает уникальным топологическим адресом, состоящим из номера шины (англ. Bus) и номеров физического (англ. Device) и логического (англ. Function) устройств [Budruk, Anderson, Shanley 2003]. Прямого метода определения слотов с установленными PCI-устройствами из среды UEFI-BIOS нет, поэтому необходимо просканировать все возможные адреса, изменяя значения номеров шин и устройств в возможных диапазонах (Bus от 0 до 255, Device от 0 до 31, Function от 0 до 7) и для каждого из вариантов осуществить попытку чтения нулевого регистра, в котором содержится информация об идентификаторе устройства (англ. Device ID, DID) и идентификаторе производителя (англ. Vendor ID, VID). Для этого требуется вычислить значение базового адреса, который состоит из номера шины, номера физического устройства и номера логического устройства при нулевом значении регистра, основываясь на формате конфигурационного адреса [PCI specification] и выполнив необходимые преобразования типов:

(UINT64) (((UINTN) Bus << 24) + ((UINTN) Dev << 16) + ((UINTN) Func << 8)).

Теперь можно получить информацию об устройстве при помощи функции Pci->Read(), передав ей в качестве параметра вычисленное значение адреса, и в случае успешной попытки чтения она вернет необходимую информацию об обнаруженном устройстве. Список полей, составляющих идентификационную информацию для PCI-устройств (структура PciDevice) c примерами заполненного содержимого, приведен в табл. 3. Значение идентификатора производителя выдается организацией PCI SIG, а значение идентификатора устройства назначается его производителем; при этом каждое из полей, указанных в табл. 3, является обязательным для любого PCI-устройства [Budruk, Anderson, Shanley 2003].

Таблица 3

Для получения доступа к информации о жестких дисках необходимо, как и в случае с PCI-устройствами, сначала получить массив дескрипторов, поддерживающих протокол EFI_DISK_INFO_ PROTOCOL_GUID. Для каждого элемента массива следует выполнить обращение к функции gBS->HandleProtocol(), чтобы определить, поддерживает ли выбранный дескриптор данный протокол. В случае успеха для полученного экземпляра устройства необходимо вызвать команду Identify(), предварительно назначив интерфейс (IDE или AHCI): в случае, если конкретное устройство не поддерживает взаимодействие в выбранном режиме (например, если это USB-устройство), происходит переход к следующему дескриптору. Список полей, составляющих идентификационную информацию для жестких дисков (структура HdDevice) c примерами заполненного содержимого приведен, в табл. 4.

Как видно из таблиц 1-4, списки полей, в совокупности составляющих идентификационную информацию для каждого типа устройств, могут с приемлемой точностью гарантировать ее уникальность для каждого из аппаратных компонент, особенно при возможности первоначальной настройки, включающей в себя заполнение необходимых полей данных в таблице SMBIOS.

Таблица 4

UEFI-приложение обладает текстовым пользовательским интерфейсом для просмотра текущей аппаратной конфигурации, сохранения новой или для отключения ее проверки, однако доступ к этим возможностям есть только в меню управления, войти в которое возможно при наличии у пользователя прав администратора. Для лаконичности вывода в меню управления аппаратной конфигурацией отображается не вся хранимая информация об устройствах, а только ее часть, хотя при сравнении идет проверка всех полей. Пароль хранится в энергонезависимой памяти компьютера NVRAM в хешированном виде с использованием алгоритма SHA256; администратор может изменить его в меню управления.

В текущей реализации средства защиты не блокируют дальнейшую загрузку операционной системы в случае обнаружения нарушения целостности аппаратной конфигурации, а только выводят сообщение об этом, однако данная функция может быть добавлена в дальнейшем при их модернизации. Для того чтобы у пользователей устройства была возможность ознакомиться с предупреждениями о нарушении целостности при их возникновении и ввести пароль администратора, UEFI-приложение после своего запуска выводит текстовое меню с пунктами пользовательского интерфейса. После этого начинается обратный отсчет времени таймаута, равного десяти секундам, после окончания которого приложение завершает свою работу и возобновляется обычная загрузка операционной системы. Если пользователь нажмет любую клавишу, кроме клавиши входа в главное меню, работа приложения также будет завершена. В случае, если будет обнаружено нарушение целостности аппаратной конфигурации (например, при удалении одного из устройств), а затем она будет восстановлена (при подключении того же устройства), предупреждения не исчезнут, но появится пояснение о том, что хотя целостность оборудования была нарушена ранее, в настоящий момент конфигурация соответствует эталонной. При отключении проверки или сохранении новой эталонной аппаратной конфигурации все предупреждения сбрасываются. По умолчанию контроль целостности отключен.

Пример работы приложения приведен на рис. 2 и 3. При первом запуске компьютера после встраивания образа UEFI-приложения в образ BIOS аппаратная конфигурация компьютера была сохранена в качестве эталонной (рис. 2). Затем установленный жесткий диск был удален, а вместо него подключен другой диск. При следующем запуске приложения было выведено предупреждение о нарушенной целостности аппаратной конфигурации с указанием того, какое устройство было добавлено, а какое - удалено (рис. 3).

Рис. 2. Вывод текущей аппаратной конфигурации компьютера из меню управления

Рис. 3. Вывод предупреждения при нарушенной целостности аппаратной конфигурации компьютера

Это предупреждение будет выводиться при каждом запуске компьютера (и, соответственно, приложения) до тех пор, пока администратор не сохранит новую эталонную конфигурацию или не отключит проверку в меню управления, войти в которое он может, нажав клавишу `C' без ожидания окончания отсчета таймаута после запуска приложения.

Заключение

В статье предлагается метод проверки целостности аппаратной конфигурации, основанный на использовании низкоуровневого приложения, работающего в среде UEFI-BIOS. Работа системы не зависит от наличия операционной системы и от используемой версии BIOS, а также не требует для своего функционирования подключения дополнительных аппаратных компонентов. Приложение начинает свое выполнение после прохождения основных фаз загрузки базовой системы ввода-вывода, осуществляет проверку целостности аппаратной конфигурации, выводит предупреждение в случае нарушения целостности. Если пользователь не нажмет клавишу для входа в меню управления, по истечении временного интервала, отсчитываемого таймером, оно завершает свою работу, передавая управление загрузчику операционной системы. Однако такая система может быть полезной, только если контролирующая сторона (производитель оборудования или администратор) будет иметь доступ к устройству (например, при проверке выполнения условий эксплуатации для определения возможности гарантийного обслуживания). В качестве дальнейших направлений усовершенствования системы можно перечислить следующие: выполнение шифрования сохраненной эталонной конфигурации для предотвращения ее изменения в NVRAM-памяти; определение факта вскрытия корпуса при наличии встроенного датчика на материнской плате; добавление возможности блокировки загрузки операционной системы при обнаружении вскрытия.

Литература

1. Budruk, Anderson, Shanley 2003 - Budruk R, Anderson D, Stanley T. PCI Express System Architecture. Boston, MA: Addison-Wesley Developer's Press, 2003. DMTF 2020 - DMTF. System Management BIOS (SMBIOS) Reference Specification Version 3.4.0 [Электронный ресурс]. URL: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf (дата обращения 10 декабря 2020).

2. Microsoft 2020 - Microsoft, PE Format [Электронный ресурс]. URL: https:// docs.microsoft.com/en-us/windows/win32/debug/pe-format (дата обращения 10 декабря 2020).

3. Tianocore 2018a - Tianocore, EDK II Driver Writer's Guide [Электронный ресурс]. URL: https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide (дата обращения 10 декабря 2020).

4. Tianocore 2018b - Tianocore, EDK II Module Writer's Guide [Электронный ресурс]. URL: https://edk2-docs.gitbook.io/edk-ii-module-writer-s-guide (дата обращения 10 декабря 2020).

5. Unified Extensible Firmware 2019 - Unified Extensible Firmware Interface (UEFI) Specification Version 2.8 [Электронный ресурс]. URL: https:// uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf (дата обращения 10 декабря 2020).

6. Zimmer, Rothman, Marisetty 2010 - Zimmer V., Rothman M, Marisetty S. Beyond BIOS: Developing with the Unified Extensible Firmware Interface, 2nd ed. Hudson, MA: Intel Press, 2010.

References

1. Budruk R., Anderson D. and Shanley T. (2003), PCI Express System Architecture, Addison-Wesley Developer's Press, Boston, USA.

2. DMTF, System Management BIOS (SMBIOS) Reference Specification Version 3.4.0 (2020), [Online], available at: https://www.dmtf.org/sites/default/ files/standards/documents/DSP0134_3.4.0.pdf (Accessed 10 December 2020).

3. Microsoft, PE Format (2020), [Online], available at: https://docs.microsoft. com/en-us/windows/win32/debug/pe-format (Accessed 10 December 2020).

4. Tianocore, EDK II Driver Writer's Guide (2018), [Online], available at: https:// edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide (Accessed 10 December 2020).

5. Tianocore, EDK II Module Writer's Guide (2018), [Online], available at: https:// edk2-docs.gitbook.io/edk-ii-module-writer-s-guide (Accessed 10 December 2020).

6. Unified Extensible Firmware Interface (UEFI) Specification Version 2.8 (2019), [Online], available at: https://uefi.org/sites/default/files/resources/ UEFI_Spec_2_8_final.pdf (Accessed 10 December 2020).

7. Zimmer V., Rothman M. and Marisetty S. (2010), Beyond BIOS: Developing with the Unified Extensible Firmware Interface, 2nd ed., Intel Press, Hudson, USA.

Размещено на Allbest.ru