УЕФИ

Единый расширяемый интерфейс прошивки

Аббревиатура	УЕФИ
Статус	Опубликовано
Год начался	2006
Последняя версия	2.10 29 августа 2022 г.
Организация	Форум UEFI
Сопутствующие стандарты	ACPI , инициализация платформы UEFI
Предшественник	совместимый с IBM PC BIOS,
Домен	Прошивка
Веб-сайт	УЭФИ .org

Меню выбора порядка загрузки на Lenovo ThinkPad T470 с UEFI

Реализация UEFI обычно хранится в NOR на основе EEPROM , расположенном на материнской плате . Они могут использовать разные протоколы ввода-вывода, но SPI является наиболее распространенным.

Единый расширяемый интерфейс прошивки ( UEFI , / ˈ juː ɪ f aɪ / или как аббревиатура) — спецификация , определяющая архитектуру платформы, микропрограммы используемой для загрузки аппаратного обеспечения компьютера, и ее интерфейс взаимодействия с операционной системой . Примерами прошивок, реализующих данную спецификацию, являются AMI Aptio , Phoenix SecureCore , TianoCore EDK II , InsydeH2O . UEFI заменяет BIOS , который присутствовал в загрузочном ПЗУ всех персональных компьютеров , совместимых с IBM PC . хотя он может обеспечить обратную совместимость с BIOS при использовании загрузки CSM . Intel разработала оригинальную спецификацию расширяемого интерфейса прошивки ( EFI ). Некоторые методы и форматы данных EFI повторяют методы Microsoft Windows . В 2005 году UEFI прекратил поддержку EFI 1.10 (последняя версия EFI).

UEFI не зависит от платформы и языка программирования, но C. для эталонной реализации TianoCore EDKII используется

В отличие от своего предшественника BIOS, который является стандартом де-факто, первоначально созданным IBM как проприетарное программное обеспечение, UEFI является открытым стандартом, поддерживаемым отраслевым консорциумом .

История

Первоначальная мотивация для EFI возникла во время ранней разработки первых систем Intel–HP Itanium в середине 1990-х годов. Ограничения BIOS (такие как 16-битный реальный режим , адресная память 1 МБ, программирование на языке ассемблера и аппаратное обеспечение PC AT ) стали слишком ограничительными для более крупных серверных платформ, на которые ориентировался Itanium. Попытки решить эти проблемы начались в 1998 году и первоначально назывались Intel Boot Initiative . Позже он был переименован в Extensible Firmware Interface (EFI).

Первая реализация UEFI с открытым исходным кодом , Tiano, была выпущена Intel в 2004 году. С тех пор Tiano был заменен EDK. и ЭДК2 и сейчас поддерживается сообществом TianoCore.

В июле 2005 года Intel прекратила разработку спецификации EFI версии 1.10 и представила ее на Unified EFI Forum , который разработал спецификацию как Unified Extensible Firmware Interface (UEFI). Исходная спецификация EFI по-прежнему принадлежит Intel, которая предоставляет лицензии исключительно для продуктов на основе EFI, но спецификация UEFI принадлежит UEFI Forum.

Версия 2.0 спецификации UEFI была выпущена 31 января 2006 года. В нее добавлены криптография и безопасность.

Версия 2.1 спецификации UEFI была выпущена 7 января 2007 года. В нее добавлена ​​сетевая аутентификация и архитектура пользовательского интерфейса («Инфраструктура человеческого интерфейса» в UEFI).

В октябре 2018 года компания Arm анонсировала Arm ServerReady — программу сертификации соответствия требованиям для размещения стандартных готовых операционных систем и гипервизоров на серверах на базе Arm. Программа требует, чтобы встроенное ПО системы соответствовало базовым требованиям к загрузке сервера (SBBR). SBBR требует соответствия UEFI, ACPI и SMBIOS . В октябре 2020 года Arm объявила о расширении программы на рынок периферийных устройств и Интернета вещей . Новое имя программы — Arm SystemReady . Arm SystemReady определила спецификацию базовых требований к загрузке ( BBR ), которая в настоящее время предоставляет три рецепта, два из которых связаны с UEFI: 1) SBBR: требует соответствия UEFI, ACPI и SMBIOS, подходящего для операционных сред корпоративного уровня, таких как Windows, Red Hat Enterprise. Linux и VMware ESXi; и 2) EBBR: требуется соответствие набору интерфейсов UEFI, как определено в Требованиях к встроенной базовой загрузке ( EBBR ), подходящих для встроенных сред, таких как Yocto. Многие дистрибутивы Linux и BSD поддерживают оба рецепта.

В декабре 2018 года Microsoft анонсировала Project Mu, ответвление TianoCore EDK2, используемое в Microsoft Surface и Hyper-V продуктах . Проект продвигает идею « Прошивка как услуга» .

Последняя спецификация UEFI, версия 2.10, была опубликована в августе 2022 года.

Преимущества

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

• Возможность загрузки диска, содержащего большие разделы (более 2 ТБ ) с таблицей разделов GUID (GPT).
• Гибкая предоперационная среда, включая сетевые возможности, графический интерфейс, многоязычность
• 32-битная (например, IA-32 , ARM32 ) или 64-битная (например, x64 , AArch64 ) среда до ОС
• на языке Си Программирование
• Программирование на Python с использованием интерпретатора Python для оболочки UEFI
• Модульная конструкция
• Обратная и прямая совместимость

Совместимость

Совместимость процессоров

Начиная с версии 2.5 существуют привязки процессоров для Itanium, x86, x86-64, ARM (AArch32) и ARM64 (AArch64). только процессоры с прямым порядком байтов . Поддерживаются Неофициальная поддержка UEFI для POWERPC64 находится в стадии разработки путем внедрения TianoCore поверх OPAL. уровень абстракции OpenPOWER, работающий в режиме прямого порядка байтов. Подобные проекты существуют для MIPS и RISC-V . Начиная с UEFI 2.7, привязки процессоров RISC-V официально установлены для 32-, 64- и 128-битных режимов.

Стандартный BIOS ПК ограничен режимом 16-битного процессора и 1 МБ адресуемой памяти, что является результатом конструкции, основанной на IBM 5150 , в которой использовался 16-битный процессор Intel 8088 . Для сравнения, режим процессора в среде UEFI может быть либо 32-битным ( IA-32 , AArch32), либо 64-битным ( x86-64 , Itanium и AArch64). 64-битные реализации прошивки UEFI поддерживают длинный режим , который позволяет приложениям в среде предварительной загрузки использовать 64-битную адресацию для получения прямого доступа ко всей памяти машины.

UEFI требует, чтобы размер прошивки и загрузчика операционной системы (или ядра) соответствовали; то есть 64-битная реализация прошивки UEFI может загружать только загрузчик или ядро ​​64-битной операционной системы (ОС) (если не используется устаревшая загрузка на основе CSM), и то же самое относится и к 32-битной версии. После перехода системы от «Служб загрузки» к «Службам выполнения» управление берет на себя ядро ​​операционной системы. На этом этапе ядро ​​может изменить режимы процессора, если пожелает, но это запрещает использование служб времени выполнения (если ядро ​​снова не переключится обратно). Начиная с версии 3.15, ядро ​​Linux поддерживает загрузку 64-битных ядер на 32-битных реализациях встроенного ПО UEFI, работающих на процессорах x86-64 , с поддержкой передачи обслуживания UEFI от загрузчика UEFI в качестве требования. Протокол передачи обслуживания UEFI дедуплицирует код инициализации UEFI между ядром и загрузчиками UEFI, оставляя инициализацию выполняться только загрузочной заглушкой UEFI ядра Linux .

Совместимость дисковых устройств

См. также: GPT § Поддержка операционных систем и Protective MBR.

В дополнение к стандартной схеме разделов диска ПК, в которой используется основная загрузочная запись (MBR), UEFI также работает со схемой разделов таблицы разделов GUID (GPT), которая свободна от многих ограничений MBR. В частности, MBR ограничивает количество и размер разделов диска (до четырех основных разделов на диск и до 2 ТБ (2 × 2 ⁴⁰ байт ) на диск) ослаблены. В частности, GPT допускает максимальный размер диска и раздела 8 ЗиБ (8 × 2 ⁷⁰ байты) .

Линукс

См. также: Системный раздел EFI § Linux.

Поддержка GPT в Linux включается включением опции CONFIG_EFI_PARTITION (Поддержка разделов EFI GUID) во время настройки ядра. Эта опция позволяет Linux распознавать и использовать GPT-диски после того, как встроенное ПО системы передает контроль над системой Linux.

Для обратной совместимости Linux может использовать GPT-диски в системах на базе BIOS как для хранения данных, так и для загрузки, поскольку и GRUB 2 , и Linux поддерживают GPT. Такая настройка обычно называется BIOS-GPT . Поскольку GPT включает в себя защитную MBR, компьютер на базе BIOS может загружаться с диска GPT, используя загрузчик с поддержкой GPT, хранящийся в области кода начальной загрузки защитной MBR . В случае GRUB такая конфигурация требует, чтобы загрузочный раздел BIOS для GRUB встраивал свой код второго этапа из-за отсутствия пробела после MBR в разделенных GPT дисках (который перехватывается первичным заголовком GPT и таблицей первичных разделов GPT). ). 1 МБ Обычно размер , глобальный уникальный идентификатор (GUID) этого раздела в схеме GPT: 21686148-6449-6E6F-744E-656564454649 и используется GRUB только в настройках BIOS-GPT. С точки зрения GRUB, в случае разделения MBR такого типа раздела не существует. Этот раздел не требуется, если система основана на UEFI, поскольку в этом случае встраивание кода второго этапа не требуется.

Системы UEFI могут получать доступ к GPT-дискам и загружаться непосредственно с них, что позволяет Linux использовать методы загрузки UEFI. Загрузка Linux с GPT-дисков в системах UEFI предполагает создание системного раздела EFI (ESP), который содержит приложения UEFI, такие как загрузчики, ядра операционной системы и служебное программное обеспечение. Такая установка обычно называется UEFI-GPT , при этом рекомендуется, чтобы ESP имел размер не менее 512 МБ и был отформатирован в файловой системе FAT32 для максимальной совместимости.

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

Microsoft Windows

64-разрядные версии Windows Vista SP1 и более поздних версий, а также 64-разрядные версии Windows 8 , 8.1 , 10 и 11 могут загружаться с GPT-диска размером более 2 ТБ .

Функции

Услуги

Пример переменных UEFI

EFI определяет два типа служб: службы загрузки и службы времени выполнения . Службы загрузки доступны только до тех пор, пока прошивка владеет платформой (т. е. до того, как ExitBootServices() вызов), и они включают в себя текстовые и графические консоли на различных устройствах, а также шинные, блочные и файловые службы. Службы времени выполнения по-прежнему доступны во время работы операционной системы; они включают в себя такие службы, как дата, время и доступ к NVRAM .

Службы протокола вывода графики (GOP)

Протокол вывода графики (GOP) предоставляет услуги во время выполнения; см. также раздел «Графические функции» ниже. Операционной системе разрешено напрямую записывать данные в кадровый буфер, предоставляемый GOP, во время режима выполнения.

UEFI карты памяти Службы

SMM -услуги

ACPI -сервисы

SMBIOS Службы

Службы Devicetree (для RISC-процессоров)

Переменные услуги

Переменные UEFI позволяют хранить данные, в частности энергонезависимые. Некоторые переменные UEFI являются общими для встроенного ПО платформы и операционных систем. Пространства имен переменных идентифицируются идентификаторами GUID, а переменные представляют собой пары ключ/значение. Например, переменные UEFI можно использовать для хранения сообщений о сбоях в NVRAM после сбоя, чтобы операционная система могла их получить после перезагрузки.

Службы времени

UEFI предоставляет службы времени. аппаратные часы реального времени на местное время или UTC. Службы времени включают поддержку полей часового пояса и перехода на летнее время, которые позволяют установить На машинах, использующих часы реального времени PC-AT, по умолчанию аппаратные часы по-прежнему должны быть установлены на местное время для совместимости с Windows на базе BIOS. если не используются последние версии и запись в реестре Windows не указывает на использование UTC.

Приложения

Взаимодействие между менеджером загрузки EFI и драйверами EFI

Помимо загрузки ОС, UEFI может запускать приложения UEFI , которые находятся в виде файлов в системном разделе EFI . Их можно выполнить из оболочки UEFI, диспетчера загрузки встроенного ПО или других приложений UEFI. Приложения UEFI можно разрабатывать и устанавливать независимо от производителей оригинального оборудования (OEM).

Типом приложения UEFI является загрузчик ОС, такой как GRUB , rEFInd , Gummiboot и Windows Boot Manager , который загружает некоторые файлы ОС в память и выполняет их. Кроме того, загрузчик ОС может предоставлять пользовательский интерфейс, позволяющий выбрать другое приложение UEFI для запуска. Такие утилиты, как UEFI Shell, также являются приложениями UEFI.

Протоколы

EFI определяет протоколы как набор программных интерфейсов, используемых для связи между двумя двоичными модулями. Все драйверы EFI должны предоставлять услуги другим через протоколы. Протоколы EFI аналогичны вызовам прерываний BIOS .

Драйверы устройств

В дополнение к стандартным драйверам устройств, зависящим от архитектуры набора команд , EFI предоставляет независимый от ISA драйвер устройства , хранящийся в энергонезависимой памяти в виде байт-кода EFI или EBC . В системной прошивке имеется интерпретатор изображений EBC. В этом смысле EBC аналогичен Open Firmware , независимой от ISA прошивке, используемой, среди прочего, в PowerPC на базе компьютерах Apple Macintosh и Sun Microsystems SPARC .

Некоторые драйверы EFI, зависящие от архитектуры (не байт-код EFI), для некоторых типов устройств могут иметь интерфейсы для использования ОС. Это позволяет ОС использовать EFI для драйверов для выполнения основных графических и сетевых функций до загрузки драйверов, специфичных для операционной системы, и в случае их загрузки.

В других случаях драйвером EFI могут быть драйверы файловой системы, позволяющие загрузку с дисковых томов других типов. Примеры включают efifs для 37 файловых систем (на основе кода GRUB2 ), используется Rufus для цепной загрузки NTFS ESP.

Графические возможности

Спецификация EFI 1.0 определила протокол UGA (универсальный графический адаптер) как способ поддержки графических функций. UEFI не включил UGA и заменил его на GOP (протокол вывода графики) .

В UEFI 2.1 определена «инфраструктура пользовательского интерфейса» (HII) для управления пользовательским вводом, локализованными строками, шрифтами и формами (в смысле HTML ). Они позволяют производителям оригинального оборудования (OEM) или независимым поставщикам BIOS (IBV) разрабатывать графические интерфейсы для конфигурации перед загрузкой. UEFI использует UTF-16 по умолчанию для кодирования строк.

Большинство ранних реализаций прошивки UEFI были консольными. Сегодня многие реализации встроенного ПО UEFI основаны на графическом интерфейсе.

Системный раздел EFI

Основная статья: системный раздел EFI

Системный раздел EFI, часто сокращенно ESP, представляет собой раздел устройства хранения данных , который используется на компьютерах, соответствующих спецификации UEFI. Доступ к прошивке UEFI при включении компьютера сохраняет приложения UEFI и файлы, необходимые для запуска этих приложений, включая загрузчики операционной системы . Поддерживаемые схемы таблиц разделов включают MBR и GPT , а также тома El Torito на оптических дисках. Для использования в ESP UEFI определяет конкретную версию файловой системы FAT , которая поддерживается как часть спецификации UEFI и независимо от исходной спецификации FAT, включая файловые системы FAT32 , FAT16 и FAT12 . ESP также предоставляет место для загрузочного сектора в рамках обратной совместимости BIOS.

Загрузка

Загрузка UEFI

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

Загрузчики ОС могут автоматически обнаруживаться с помощью UEFI, что позволяет легко загружать со съемных устройств, таких как USB-накопители . Это автоматическое обнаружение основано на стандартизированных путях к файлам загрузчика ОС, причем путь варьируется в зависимости от архитектуры компьютера . Формат пути к файлу определяется как <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI ; например, путь к файлу загрузчика ОС в системе x86-64 : \efi\boot\bootx64.efi , и \efi\boot\bootaa64.efi на архитектуре ARM64.

Процесс загрузки

Загрузка систем UEFI с дисков с разделами GPT обычно называется загрузкой UEFI-GPT . Несмотря на то, что спецификация UEFI требует полной поддержки таблиц разделов MBR, некоторые реализации встроенного ПО UEFI немедленно переключаются на загрузку CSM на основе BIOS в зависимости от типа таблицы разделов загрузочного диска, эффективно предотвращая выполнение загрузки UEFI из системного раздела EFI на дисках с разделами MBR. Такая схема загрузки обычно называется UEFI-MBR .

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

Загрузка CSM

Чтобы обеспечить обратную совместимость, реализации встроенного ПО UEFI на компьютерах класса ПК могут поддерживать загрузку в устаревшем режиме BIOS с дисков, разделенных MBR, через модуль поддержки совместимости (CSM) , который обеспечивает совместимость с устаревшим BIOS. В этом сценарии загрузка выполняется так же, как и в устаревших системах на базе BIOS, игнорируя таблицу разделов и полагаясь на содержимое загрузочного сектора .

Загрузка в стиле BIOS с дисков, разделенных MBR, обычно называется BIOS-MBR , независимо от того, выполняется ли она в системах UEFI или устаревших системах на базе BIOS. Кроме того, возможна загрузка устаревших систем на базе BIOS с GPT-дисков, и такая схема загрузки обычно называется BIOS-GPT .

Модуль поддержки совместимости устаревшие операционные системы и некоторые устаревшие дополнительные ПЗУ , которые не поддерживают UEFI. позволяет использовать Он также предоставляет необходимые устаревшего режима управления системой функции (SMM), называемые CompatibilitySmm , в качестве дополнения к функциям, предоставляемым UEFI SMM. Примером такой устаревшей функциональности SMM является обеспечение устаревшей поддержки USB для клавиатуры и мыши путем эмуляции их классических PS/2 . аналогов

В ноябре 2017 года Intel объявила, что планирует прекратить поддержку CSM для клиентских платформ к 2020 году.

В июле 2022 года «Лаборатория Касперского» опубликовала информацию о рутките, предназначенном для последовательной загрузки вредоносного кода на компьютерах с чипсетом Intel H81 и модулем поддержки совместимости затронутых материнских плат.

В августе 2023 года Intel объявила, что планирует прекратить поддержку CSM для серверных платформ к 2024 году.

На сегодняшний день все компьютеры на базе платформ Intel больше не поддерживают CSM.

Сетевая загрузка

Спецификация UEFI включает поддержку загрузки по сети через среду Preboot eXecution Environment (PXE). загрузки PXE Сетевые протоколы включают интернет-протокол ( IPv4 и IPv6 ), протокол пользовательских дейтаграмм (UDP), протокол динамической конфигурации хоста (DHCP), тривиальный протокол передачи файлов (TFTP) и iSCSI .

Образы ОС можно удаленно хранить в сетях хранения данных (SAN), используя интерфейс малых компьютерных систем Интернета (iSCSI) и Fibre Channel over Ethernet (FCoE) в качестве поддерживаемых протоколов для доступа к SAN.

В версии 2.5 спецификации UEFI добавлена ​​поддержка доступа к загрузочным образам через HTTP .

Безопасная загрузка

См. Также: Критика безопасной загрузки

Пример активной безопасной загрузки, обнаруженной менеджером rEFInd загрузки

Спецификация UEFI определяет протокол, известный как Secure Boot , который может защитить процесс загрузки, предотвращая загрузку драйверов UEFI или загрузчиков ОС, которые не подписаны приемлемой цифровой подписью . Механические детали того, как именно должны быть подписаны эти драйверы, не уточняются. Когда безопасная загрузка включена, она изначально переводится в режим «настройки», который позволяет записать в прошивку открытый ключ, известный как «ключ платформы» (PK). После записи ключа Secure Boot переходит в «пользовательский» режим, в котором прошивкой могут быть загружены только драйверы UEFI и загрузчики ОС, подписанные ключом платформы. Дополнительные «ключи обмена ключами» (KEK) могут быть добавлены в базу данных, хранящуюся в памяти, чтобы разрешить использование других сертификатов, но они все равно должны иметь соединение с частной частью ключа платформы. Безопасную загрузку также можно перевести в «Пользовательский» режим, при котором в систему можно добавить дополнительные открытые ключи, не соответствующие закрытому ключу.

Безопасная загрузка поддерживается Windows 8 и 8.1 , Windows Server 2012 и 2012 R2, Windows 10 , Windows Server 2016 , 2019 и 2022 , а также Windows 11 , VMware vSphere 6.5. и ряд дистрибутивов Linux, включая Fedora (начиная с версии 18), openSUSE (начиная с версии 12.3), RHEL (начиная с версии 7), CentOS (начиная с версии 7). ), Debian (начиная с версии 10), Ubuntu (начиная с версии 12.04.2), Linux Mint (начиная с версии 21.3)., и ОС AlmaLinux (начиная с версии 8.4 ). По состоянию на январь 2024 г. Поддержка FreeBSD находится на стадии планирования.

оболочка UEFI

Пример сеанса оболочки UEFI 2.2

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

Исходный код оболочки UEFI можно загрузить из Intel проекта TianoCore UDK/EDK2. Также доступен готовый ShellBinPkg. Shell v2 лучше всего работает в системах UEFI 2.3+ и в этих системах рекомендуется использовать вместо Shell v1. Shell v1 должен работать во всех системах UEFI.

системы Методы, используемые для запуска оболочки UEFI, зависят от производителя и модели материнской платы . Некоторые из них уже предоставляют прямую возможность настройки прошивки для запуска, например, скомпилированную версию оболочки x86-64 необходимо сделать доступной как <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Некоторые другие системы имеют уже встроенную оболочку UEFI, которую можно запустить с помощью соответствующих комбинаций клавиш. Для других систем решением является либо создание соответствующего USB-накопителя, либо добавление вручную ( bcfg) вариант загрузки, связанный с скомпилированной версией оболочки.

Команды

Ниже приведен список команд, поддерживаемых оболочкой EFI.

• псевдоним
• атрибут
• БКФГ
• компакт-диск
• клс
• комп
• КП
• дата
• двухместный
• д
• dmpstore
• эхо
• Эд30
• Эддебаг
• редактировать
• ошибаться
• гид
• помощь
• нагрузка
• лс
• карта
• мем
• карта памяти
• мкдир
• мм
• режим
• устанавливать
• пауза
• PCI
• перезагрузить
• РМ
• набор
• ларек
• время
• тип
• разгружать
• видеть
• том

Расширения

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

UEFI-капсула

UEFI Capsule определяет интерфейс обновления прошивки для ОС, который позиционируется как современный и безопасный. Windows 8 , Windows 8.1 , Windows 10 , и Fwupd для Linux поддерживают UEFI Capsule.

Аппаратное обеспечение

Как и BIOS , UEFI инициализирует и тестирует аппаратные компоненты системы (например, обучение памяти, обучение каналу PCIe, обучение каналу USB), а затем загружает загрузчик с запоминающего устройства или через сетевое соединение . В системах x86 прошивка UEFI обычно хранится во флэш-чипе NOR материнской платы.

Классы

Машины UEFI могут иметь один из следующих классов, которые использовались для облегчения перехода на UEFI:

• Класс 0: устаревший BIOS
• Класс 1: UEFI с интерфейсом CSM и без внешнего интерфейса UEFI. Единственные интерфейсы UEFI являются внутренними встроенного ПО.
• Класс 2: UEFI с CSM и внешними интерфейсами UEFI, например. Загрузка UEFI.
• Класс 3: UEFI без интерфейса CSM и с внешним интерфейсом UEFI.
• Класс 3+: класс UEFI 3 с включенной безопасной загрузкой.

Начиная с процессоров Intel Core 10-го поколения, Intel больше не предоставляет Legacy Video BIOS для iGPU ( Intel Graphics Technology ). Для загрузки Legacy с этими процессорами требуется Legacy Video BIOS, который по-прежнему может предоставляться видеокартой.

Этапы загрузки

SEC – Фаза безопасности

Это первый этап загрузки UEFI, но ему может предшествовать двоичный код, специфичный для платформы. (например, Intel ME , AMD PSP ЦП , микрокод ). Он состоит из минимального кода, написанного на языке ассемблера для конкретной архитектуры. Он инициализирует временную память (часто кэш ЦП в виде ОЗУ или встроенную SRAM SoC, CAR) и служит программным корнем доверия системы с возможностью проверки PEI перед передачей.

PEI — инициализация перед EFI

Второй этап загрузки UEFI состоит из диспетчера с учетом зависимостей, который загружает и запускает модули PEI (PEIM) для выполнения задач ранней инициализации оборудования, таких как инициализация основной памяти (инициализация контроллера памяти и DRAM ) и операций восстановления прошивки. Кроме того, он отвечает за обнаружение текущего режима загрузки и обработку многих операций ACPI S3. В случае возобновления ACPI S3 он отвечает за восстановление многих аппаратных регистров в состояние перед спящим режимом. PEI также использует CAR.

DXE — среда выполнения драйвера

Этот этап состоит из модулей C и диспетчера, учитывающего зависимости. Теперь, когда основная память доступна, процессор, набор микросхем, материнская плата и другие устройства ввода-вывода инициализируются в DXE и BDS.

BDS – выбор загрузочного устройства

BDS является частью DXE. На этом этапе инициализируются загрузочные устройства, драйверы UEFI или дополнительные ПЗУ устройств PCI выполняются в соответствии с конфигурацией системы и обрабатываются параметры загрузки.

TSL – переходная нагрузка системы

Это этап между выбором загрузочного устройства и передачей ОС. На этом этапе можно войти в оболочку UEFI или выполнить приложение UEFI, например загрузчик ОС.

РТ – Время выполнения

UEFI переключается на операционную систему (ОС) после ExitBootServices() выполняется. UEFI-совместимая ОС теперь отвечает за выход из служб загрузки, запуская прошивку для выгрузки всего ненужного кода и данных, оставляя только код/данные служб времени выполнения, например SMM и ACPI . Типичная современная ОС предпочитает использовать собственные программы (например, драйверы ядра ) для управления аппаратными устройствами.

Если используется устаревшая ОС, CSM обработает этот вызов, гарантируя, что система совместима с ожиданиями устаревшего BIOS.

Использование

Реализации

Microsoft Surface UEFI, UEFI, используемый на всех моделях Surface, выпущенных после 2015 года.

Реализация EFI от Intel — это Intel Platform Innovation Framework под кодовым названием Tiano . Tiano работает на процессорах Intel XScale , Itanium , IA-32 и x86-64 и является проприетарным программным обеспечением, хотя часть кода была выпущена под лицензией BSD или Eclipse Public License (EPL) как TianoCore EDK II . TianoCore можно использовать в качестве полезной нагрузки для coreboot .

Реализация UEFI компанией Phoenix Technologies получила название SecureCore Technology (SCT). American Megatrends предлагает собственную реализацию прошивки UEFI, известную как Aptio. в то время как Insyde Software предлагает InsydeH2O, и Byosoft предлагает ByoCore.

В декабре 2018 года Microsoft выпустила версию с открытым исходным кодом своей реализации UEFI на базе TianoCore EDK2 из линейки Surface — Project Mu .

Реализация UEFI API была введена в универсальный загрузчик ( Das U-Boot ) в 2017 году. В ARMv8 с архитектурой дистрибутивах Linux для загрузки используется реализация U-Boot UEFI в сочетании с GNU GRUB (например, SUSE Linux ), то же самое справедливо и для OpenBSD. Для загрузки из iSCSI iPXE можно использовать как приложение UEFI, загружаемое с помощью U-Boot.

Платформы

рабочие станции и серверы Intel Первые Itanium , выпущенные в 2000 году, использовали EFI 1.02.

системы Hewlett-Packard Первые Itanium 2 , выпущенные в 2002 году, реализовали EFI 1.10; они могли загружать Windows , Linux , FreeBSD и HP-UX ; OpenVMS добавила возможность UEFI в июне 2003 года.

В январе 2006 года компания Apple Inc. выпустила свои первые компьютеры Macintosh на базе процессоров Intel . В этих системах использовалась EFI вместо открытой прошивки , которая использовалась в предыдущих системах на базе PowerPC. 5 апреля 2006 года Apple впервые выпустила Boot Camp , который создает диск с драйверами Windows и инструмент неразрушающего разбиения на разделы, позволяющий устанавливать Windows XP или Vista без переустановки Mac OS X (теперь macOS). Также было выпущено обновление прошивки, которое добавило совместимость с BIOS к реализации EFI. Последующие модели Macintosh поставлялись с более новой прошивкой.

В 2005 году более миллиона систем Intel были поставлены с реализацией Intel UEFI. Новые мобильные, настольные и серверные продукты, использующие реализацию UEFI от Intel, начали поставляться в 2006 году. Например, платы, использующие набор микросхем серии Intel 945, используют реализацию встроенного ПО UEFI от Intel.

С 2005 года EFI также реализуется на архитектурах, отличных от ПК, например, во встроенных системах на базе ядер XScale .

EDK (EFI Developer Kit) включает в себя целевой объект NT32, который позволяет запускать прошивку EFI и приложения EFI в приложении Windows . Но EDK NT32 не допускает прямого доступа к оборудованию. Это означает, что целевой объект EDK NT32 может выполнять только часть приложений и драйверов EFI.

В 2008 году все больше систем x86-64 стали использовать UEFI. Хотя многие из этих систем по-прежнему позволяют загружать только операционные системы на базе BIOS через модуль поддержки совместимости (CSM) (таким образом, они не кажутся пользователю основанными на UEFI), другие системы начали разрешать загрузку операционных систем на основе UEFI. Например, сервер IBM x3450, материнские платы MSI с ClickBIOS, ноутбуки HP EliteBook.

В 2009 году IBM поставила машины System x (x3550 M2, x3650 M2, iDataPlex dx360 M2) и BladeCenter HS22 с поддержкой UEFI. Dell поставляла серверы PowerEdge T610, R610, R710, M610 и M710 с поддержкой UEFI. Другие коммерчески доступные системы упоминаются в официальном документе UEFI.

В 2011 году крупные производители (такие как ASRock , Asus , Gigabyte и MSI ) выпустили несколько материнских плат, ориентированных на потребителя, с использованием чипсета Intel 6-й серии LGA 1155 и чипсетов AMD 9-й серии AM3+ с UEFI.

С выпуском Windows 8 в октябре 2012 года сертификационные требования Microsoft теперь требуют, чтобы компьютеры имели встроенное ПО, реализующее спецификацию UEFI. Кроме того, если компьютер поддерживает функцию « Подключенный режим ожидания » в Windows 8 (которая позволяет устройствам управлять питанием так же, как смартфоны , с почти мгновенным выходом из режима ожидания), то встроенное ПО не может содержать модуль поддержки совместимости ( ЦСМ). Таким образом, системы, поддерживающие Connected Standby, не способны загружать устаревшие операционные системы BIOS.

В октябре 2017 года Intel объявила, что к 2020 году откажется от поддержки устаревшего BIOS для ПК из всех своих продуктов в пользу UEFI Class 3. К 2019 году все компьютеры на базе платформ Intel больше не будут поддерживать устаревшую версию BIOS для ПК.

Операционные системы

Операционная система, которую можно загрузить с (U)EFI, называется операционной системой с поддержкой (U)EFI, что определяется спецификацией (U)EFI. Здесь термин «загрузка с (U)EFI» означает непосредственную загрузку системы с использованием загрузчика операционной системы (U)EFI, хранящегося на любом устройстве хранения данных. Местоположение по умолчанию для загрузчика операционной системы: <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI, где может быть краткое название типа машины IA32, X64, IA64, ARM или AA64. Некоторые поставщики операционных систем могут иметь собственные загрузчики. Они также могут изменить местоположение загрузки по умолчанию.

• Ядро Linux может использовать EFI во время загрузки с начала 2000-х годов. используя загрузчик elilo EFI или, с недавних пор, EFI-версии GRUB . Grub+Linux также поддерживает загрузку из таблицы разделов GUID без UEFI. В дистрибутив Ubuntu добавлена ​​поддержка безопасной загрузки UEFI начиная с версии 12.10. Кроме того, ядро ​​Linux может быть скомпилировано с возможностью запуска в качестве загрузчика EFI самостоятельно с помощью функции загрузчика EFI.
• HP-UX использует (U)EFI в качестве механизма загрузки в системах IA-64 с 2002 года.
• OpenVMS использует EFI в IA-64 с момента его первоначальной оценочной версии в декабре 2003 года, а в производственных версиях — с января 2005 года. OpenVMS на x86-64 также использует UEFI для загрузки операционной системы.
• Apple использует EFI для своей линейки компьютеров Mac на базе процессоров Intel . Mac OS X v10.4 Tiger и Mac OS X v10.5 Leopard реализуют EFI v1.10 в 32-битном режиме даже на новых 64-битных процессорах, но полная поддержка появилась в OS X v10.8 Mountain Lion .
• Версии Itanium для Windows 2000 (Advanced Server Limited Edition и Datacenter Server Limited Edition; на основе предварительной версии кода Windows Server 2003 ) реализовали EFI 1.10 в 2002 году. 64-разрядная версия Windows XP , Windows 2000 Advanced Server Limited Edition (предварительная версия) выпуск Windows Server 2003) и Windows Server 2003 для IA-64 , все из которых предназначены для семейства процессоров Intel Itanium , реализуют EFI, требование платформы согласно спецификации DIG64 .
• Microsoft представила UEFI для операционных систем Windows x64 с Windows Vista SP1 и Windows Server 2008 только UGA (универсальный графический адаптер) 1.1 или Legacy BIOS INT 10h , однако поддерживается ; Протокол вывода графики (GOP) не поддерживается. Таким образом, компьютеры под управлением 64-разрядных версий Windows Vista SP1 , Windows Vista SP2 , Windows 7 , Windows Server 2008 и Windows Server 2008 R2 совместимы с UEFI Class 2. 32-битный UEFI изначально не поддерживался, поскольку поставщики не были заинтересованы в выпуске собственной 32-битной прошивки UEFI из-за массового статуса 64-битных вычислений . В Windows 8 наконец-то появились дополнительные оптимизации для систем UEFI, включая поддержку протокола вывода графики (GOP). более быстрый запуск, поддержка 32-битного UEFI и поддержка безопасной загрузки. Microsoft начала требовать UEFI для запуска Windows с Windows 11 . с выпусками IoT Enterprise Windows 11, начиная с версии 24H2, освобождены от этого требования.
• 5 марта 2013 года Фонд FreeBSD предоставил грант разработчику, стремящемуся добавить поддержку UEFI в ядро ​​и загрузчик FreeBSD . Изменения изначально хранились в отдельной ветке исходного кода FreeBSD, но были объединены с основным исходным кодом 4 апреля 2014 г. (версия 264095); изменения также включают поддержку в установщике. Поддержка загрузки UEFI для amd64 впервые появилась во FreeBSD 10.1, а для Arm64 — в FreeBSD 11.0.
• Oracle Solaris 11.1 и более поздние версии поддерживают загрузку UEFI для систем x86 с микропрограммой UEFI версии 2.1 или более поздней. GRUB 2 используется в качестве загрузчика на x86.
• OpenBSD 5.9 представила поддержку загрузки UEFI для 64-битных систем x86 с использованием собственного специального загрузчика, OpenBSD 6.0 расширила эту поддержку, включив в нее ARMv7.
• ArcaOS поддерживает загрузку UEFI начиная с версии 5.1. Поддержка UEFI в ArcaOS эмулирует определенные функции BIOS , от которых зависит операционная система (в частности, прерывания INT 10H и INT 13H ).

С виртуализацией

• Виртуальные машины HP Integrity обеспечивают загрузку UEFI на серверах HP Integrity. Он также предоставляет виртуализированную среду UEFI для гостевых ОС, поддерживающих UEFI.
• Intel размещает проект открытой прошивки виртуальной машины на SourceForge.
• Программное обеспечение VMware Fusion 3 для Mac OS X может загружать виртуальные машины Mac OS X Server с использованием UEFI.
• VMware Workstation до версии 11 неофициально поддерживает UEFI, но включается вручную путем редактирования файла .vmx. VMware Workstation версии 11 и выше поддерживает UEFI независимо от того, основана ли физическая хост-система на UEFI. В VMware Workstation 14 (и, соответственно, Fusion 10) добавлена ​​поддержка функции безопасной загрузки UEFI.
• Гипервизор VMware ESXi 5.0 официально поддерживает UEFI. В версии 6.5 добавлена ​​поддержка безопасной загрузки.
• VirtualBox реализует UEFI начиная с версии 3.1, но ограничено операционными системами Unix/Linux и Windows 8 и более поздних версий (не работает с Windows Vista x64 и Windows 7 x64).
• QEMU / KVM можно использовать с прошивкой открытой виртуальной машины (OVMF), предоставляемой TianoCore .
• Второе поколение виртуальной машины Microsoft Hyper-V поддерживает виртуализированный UEFI.
• Экранированные виртуальные машины Google Cloud Platform поддерживают виртуализированный UEFI для включения безопасной загрузки.

Разработка приложений

Комплект разработки приложений EDK2 (EADK) позволяет использовать стандартные функции библиотеки C в приложениях UEFI. EADK можно бесплатно загрузить из проекта Intel TianoCore UDK/EDK2 SourceForge . Например, порт интерпретатора Python доступен как приложение UEFI с помощью EADK. Начиная с UDK2015 разработка переехала на GitHub.

Минималистичная программа на языке C « привет, мир », написанная с использованием EADK, выглядит похожей на свой обычный аналог на языке C :

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/ShellCEntryLib.h>

EFI_STATUS EFIAPI ShellAppMain(IN UINTN Argc, IN CHAR16 **Argv)
{
    Print(L"hello, world\n");
    return EFI_SUCCESS;
}

Критика

Многочисленные активисты за цифровые права протестовали против UEFI. Рональд Г. Миннич , соавтор coreboot , и Кори Доктороу , активист цифровых прав, раскритиковали UEFI как попытку лишить пользователя возможности по-настоящему управлять компьютером. Это не решает давнюю проблему BIOS, связанную с необходимостью использования двух разных драйверов — одного для встроенного ПО и одного для операционной системы — для большинства аппаратных средств.

Проект с открытым исходным кодом TianoCore также предоставляет UEFI. В TianoCore отсутствуют специализированные драйверы, инициализирующие функции набора микросхем, которые вместо этого предоставляются coreboot , одним из многих вариантов полезной нагрузки которого является TianoCore. Разработка coreboot требует сотрудничества производителей чипсетов для предоставления спецификаций, необходимых для разработки драйверов инициализации.

Безопасная загрузка

См. также: Windows 8 § Прием.

Примеры пользовательских открытых ключей Secure Boot

MokManager, часть загрузчика Shim

В 2011 году Microsoft объявила, что компьютеры, сертифицированные для работы с ее операционной системой Windows 8, должны поставляться с зарегистрированным открытым ключом Microsoft и включенной безопасной загрузкой. ) обвинили компанию После этого объявления критики и сторонники свободного программного обеспечения/открытого исходного кода (включая Free Software Foundation в попытке использовать функцию безопасной загрузки UEFI, чтобы помешать или полностью предотвратить установку альтернативных операционных систем, таких как Linux . Microsoft отрицает, что требование безопасной загрузки было предназначено для использования в качестве формы блокировки , и уточнила свои требования, заявив, что системы на базе x86, сертифицированные для Windows 8, должны позволять безопасной загрузке переходить в пользовательский режим или отключаться, но не в системах. с использованием архитектуры ARM . Windows 10 позволяет OEM-производителям решать, могут ли пользователи их систем x86 управлять безопасной загрузкой.

Другие разработчики выразили обеспокоенность по поводу юридических и практических вопросов реализации поддержки безопасной загрузки в системах Linux в целом. Бывший Red Hat разработчик Мэтью Гарретт отметил, что условия GNU General Public License версии 3 могут препятствовать использованию GNU GRand Unified Bootloader без раскрытия разработчиком дистрибутива закрытого ключа (однако Фонд свободного программного обеспечения с тех пор уточнил свою позицию, заверив, что ответственность за предоставление ключей лежала на производителе оборудования), и что опытным пользователям также будет сложно создавать собственные ядра , которые могли бы работать с включенной безопасной загрузкой, без их самоподписания. Другие разработчики предположили, что можно предоставить подписанные сборки Linux с другим ключом, но отметили, что будет сложно убедить OEM-производителей поставлять свои компьютеры с необходимым ключом вместе с ключом Microsoft.

В нескольких основных дистрибутивах Linux разработаны различные реализации безопасной загрузки. Сам Гаррет разработал минимальный загрузчик, известный как shim, который представляет собой предварительно скомпилированный подписанный загрузчик, позволяющий пользователю индивидуально доверять ключам, предоставляемым дистрибутивами Linux. Ubuntu 12.10 использует более старую версию оболочки. предварительно настроен для использования с собственным ключом Canonical , который проверяет только загрузчик и позволяет загружать неподписанные ядра; разработчики считали, что практика подписания только загрузчика более осуществима, поскольку доверенное ядро ​​эффективно защищает только пространство пользователя , а не предзагрузочное состояние, для которого Secure Boot предназначен для дополнительной защиты. Это также позволяет пользователям создавать свои собственные ядра и использовать собственные модули ядра без необходимости перенастройки системы. Canonical также поддерживает собственный закрытый ключ для подписи установок Ubuntu, предварительно загруженных на сертифицированные OEM-компьютеры, на которых установлена ​​операционная система, а также планирует обеспечить соблюдение требований безопасной загрузки, требуя как ключа Canonical, так и ключа Microsoft (по соображениям совместимости). ) для включения в их прошивку. Fedora также использует прокладку, но требует, чтобы и ядро, и его модули были также подписаны.

Спорным является вопрос о том, необходимо ли также подписывать ядро ​​операционной системы и его модули; хотя спецификации UEFI этого не требуют, Microsoft утверждает, что их контрактные требования требуют этого, и что она оставляет за собой право отозвать любые сертификаты, используемые для подписи кода, который может быть использован для компрометации безопасности системы. В Windows, если включена безопасная загрузка, все драйверы ядра должны иметь цифровую подпись; Драйверам, отличным от WHQL, может быть отказано в загрузке. В феврале 2013 года другой разработчик Red Hat попытался представить исправление для ядра Linux, которое позволило бы анализировать подпись Microsoft с использованием аутентичного кода с использованием главного ключа X.509 , встроенного в PE- файлы, подписанные Microsoft. Однако это предложение подверглось критике со стороны создателя Linux Линуса Торвальдса , который напал на Red Hat за поддержку контроля Microsoft над инфраструктурой безопасной загрузки.

26 марта 2013 года испанская группа разработчиков бесплатного программного обеспечения Hispalinux подала официальную жалобу в Европейскую комиссию , утверждая, что требования Microsoft по безопасной загрузке для OEM-систем были «обструкционными» и антиконкурентными .

На конференции Black Hat в августе 2013 года группа исследователей безопасности представила серию эксплойтов в реализациях UEFI конкретных поставщиков, которые можно использовать для использования Secure Boot.

В августе 2016 года сообщалось, что два исследователя безопасности обнаружили ключ безопасности «золотой ключ», который Microsoft использует для подписи операционных систем. Технически ключ не был раскрыт, однако был обнаружен пригодный для использования двоичный файл, подписанный ключом. Это позволяет любому программному обеспечению работать так, как будто оно действительно подписано Microsoft, и подвергает риску атаки руткитов и буткитов . Это также делает невозможным исправление ошибки, поскольку любое исправление может быть заменено (понижено) на (подписанный) пригодный для использования двоичный файл. Microsoft ответила заявлением, что уязвимость существует только в архитектуре ARM и устройствах Windows RT , и выпустила два патча; однако исправления не устраняют (и не могут) устранить уязвимость, для устранения которой потребуется замена ключей в прошивке конечного пользователя.

1 марта 2023 года исследователи из фирмы ESET Cybersecurity сообщили о «первом действующем бутките UEFI в обход UEFI Secure Boot» под названием «BlackLotus» в результатах публичного анализа, описывающих теорию, лежащую в основе его механики, использующую патчи, которые «не (( и не может) устранить уязвимость».

Многие дистрибутивы Linux теперь поддерживают безопасную загрузку UEFI, например RHEL (RHEL 7 и новее), CentOS (CentOS 7 и новее). ), Ubuntu , Fedora , Debian (Debian 10 и более поздние версии ). ), OpenSUSE , SUSE Linux .

Проблемы с прошивкой

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

После выпуска Windows 8 в конце 2012 года было обнаружено, что некоторые модели компьютеров Lenovo с безопасной загрузкой имели встроенное ПО, которое было жестко закодировано и позволяло загружать только исполняемые файлы с именами « Windows Boot Manager » или « Red Hat Enterprise Linux », независимо от любых других параметр. Другие проблемы возникли у нескольких моделей ноутбуков Toshiba с Secure Boot, у которых отсутствовали определенные сертификаты, необходимые для правильной работы.

В январе 2013 года была опубликована ошибка, связанная с реализацией UEFI на некоторых ноутбуках Samsung , из-за которой они блокировались после установки дистрибутива Linux в режиме UEFI. Хотя первоначально обвинялись в потенциальных конфликтах с модулем ядра, предназначенным для доступа к системным функциям ноутбуков Samsung (что также побудило сопровождающих ядра отключить модуль в системах UEFI в качестве меры безопасности), Мэтью Гарретт обнаружил, что ошибка на самом деле была вызвана сохранением слишком большого количества UEFI. переменные в память и что ошибка также может возникнуть в Windows при определенных условиях. В заключение он определил, что нарушивший модуль ядра вызвал запись дампов сообщений ядра в прошивку, тем самым вызвав ошибку.

См. также

• OpenBIOS
• Инициализация платформы UEFI (UEFI PI)
• ACPI (расширенный интерфейс настройки и питания)
• BIOS управления системой (SMBIOS)
• Доверенный платформенный модуль (TPM)
• UEFIИнструмент
• Интерпретатор Python для оболочки UEFI

Дальнейшее чтение

• Циммер, Винсент; Ротман, Майкл; Хейл, Роберт (10 мая 2007 г.). «ЭФИ Архитектура» . Журнал доктора Добба . УБМ . Проверено 12 октября 2012 г.
• де Бойн Поллард, Джонатан (11 июля 2011 г.). «Процесс загрузки EFI» . Часто встречающиеся ответы . Проверено 12 октября 2012 г.
• де Бойн Поллард, Джонатан (8 декабря 2011 г.). «Процесс загрузки Windows NT 6» . Часто встречающиеся ответы . Проверено 12 октября 2012 г.
• Смит, Родерик В. (2011). «Преобразование BIOS в UEFI» . Веб-страница Родерика В. Смита . Проверено 12 октября 2012 г.
• Котари, Раджив (21 сентября 2011 г.). «UEFI – насколько это действительно важно» . Аппаратные секреты . Архивировано из оригинала 25 октября 2012 года . Проверено 12 октября 2012 г.
• Фишер, Дуг (2011). «UEFI сегодня: начальная загрузка континуума» . Журнал технологий Intel . 15 (1). Интел. ISBN  9781934053430 . Архивировано из оригинала 27 сентября 2013 года . Проверено 24 сентября 2013 г.

Внешние ссылки

• Официальный сайт
• Спецификации УЕФИ
• Инициатива EFI Framework с открытым исходным кодом, спонсируемая Intel
• Портал Intel EFI/UEFI
• Поддержка Microsoft UEFI и требования для операционных систем Windows
• Как работает функция гибридного выключения/быстрой загрузки Windows 8
• Обеспечение безопасности процесса загрузки Windows 10
• LoJax: первый руткит UEFI, обнаруженный в дикой природе, любезно предоставлен группой Sednit