Unified Extensible Firmware Interface ( UEFI , / ˈjuː ɪ f aɪ / или как аббревиатура) [b] — спецификация , определяющая архитектуру встроенного ПО платформы , используемую для загрузки аппаратного обеспечения компьютера, и ее интерфейс для взаимодействия с операционной системой . Примерами прошивок, реализующих данную спецификацию, являются AMI Aptio , Phoenix SecureCore , TianoCore EDK II , InsydeH2O . UEFI заменяет BIOS , который присутствовал в загрузочном ПЗУ всех персональных компьютеров , совместимых с IBM PC , [1] [2] , хотя он может обеспечить обратную совместимость с BIOS с использованием загрузки CSM. Intel разработала оригинальную спецификацию расширяемого интерфейса прошивки ( EFI ). Некоторые методы и форматы данных EFI повторяют методы Microsoft Windows . [3] [4] В 2005 году UEFI прекратил поддержку EFI 1.10 (последняя версия EFI).
UEFI не зависит от платформы и языка программирования, но для эталонной реализации TianoCore EDKII используется C.
В отличие от своего предшественника BIOS, который является стандартом де-факто , первоначально созданным IBM как проприетарное программное обеспечение, UEFI является открытым стандартом, поддерживаемым отраслевым консорциумом .
Первоначальная мотивация для EFI возникла во время ранней разработки первых систем Intel–HP Itanium в середине 1990-х годов. Ограничения BIOS (такие как 16-битный реальный режим , 1 МБ адресуемой памяти, [5] программирование на языке ассемблера и аппаратное обеспечение PC AT ) стали слишком жесткими для более крупных серверных платформ, на которые ориентировался Itanium. [6] Попытки решить эти проблемы начались в 1998 году и первоначально назывались Intel Boot Initiative . [7] Позже он был переименован в Extensible Firmware Interface (EFI). [8] [9]
Первая реализация UEFI с открытым исходным кодом , Tiano, была выпущена Intel в 2004 году. С тех пор Tiano был заменен EDK [10] и EDK2 [11] и теперь поддерживается сообществом TianoCore. [12]
В июле 2005 года Intel прекратила разработку спецификации EFI версии 1.10 и представила ее Unified EFI Forum , который разработал спецификацию как Unified Extensible Firmware Interface (UEFI). Исходная спецификация EFI остается собственностью Intel, которая предоставляет лицензии исключительно для продуктов на основе EFI, но спецификация UEFI принадлежит UEFI Forum. [6] [13]
Версия 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 . Проект продвигает идею « Прошивка как услуга» . [14]
Последняя спецификация UEFI, версия 2.10, была опубликована в августе 2022 года. [15]
Интерфейс, определенный спецификацией EFI, включает таблицы данных, содержащие информацию о платформе, а также службы загрузки и выполнения, доступные загрузчику ОС и ОС. Прошивка UEFI обеспечивает несколько технических преимуществ по сравнению с BIOS: [16]
Начиная с версии 2.5 существуют привязки процессоров для Itanium, x86, x86-64, ARM (AArch32) и ARM64 (AArch64). [19] Поддерживаются только процессоры с прямым порядком байтов . [20] Неофициальная поддержка UEFI для POWERPC64 находится в стадии разработки путем реализации TianoCore поверх OPAL, [21] уровня абстракции OpenPOWER, работающего в режиме с прямым порядком байтов. [22] Аналогичные проекты существуют для MIPS [23] и RISC-V . [24] Начиная с версии UEFI 2.7, привязки процессоров RISC-V официально установлены для 32-, 64- и 128-битных режимов. [25]
Стандартный BIOS ПК ограничен режимом 16-битного процессора и 1 МБ адресуемой памяти, что является результатом конструкции, основанной на IBM 5150 , в которой использовался 16-битный процессор Intel 8088 . [6] [26] Для сравнения, режим процессора в среде UEFI может быть либо 32-битным ( x86-32 , AArch32), либо 64-битным ( x86-64 , Itanium и AArch64). [6] [27] Реализации 64-битного встроенного ПО UEFI поддерживают длинный режим , который позволяет приложениям в среде предварительной загрузки использовать 64-битную адресацию для получения прямого доступа ко всей памяти машины. [28]
UEFI требует, чтобы размер прошивки и загрузчика операционной системы (или ядра) соответствовали; то есть 64-битная реализация прошивки UEFI может загружать только загрузчик или ядро 64-битной операционной системы (ОС) (если не используется устаревшая загрузка на основе CSM), и то же самое относится и к 32-битной версии. После перехода системы от «Служб загрузки» к «Службам выполнения» управление берет на себя ядро операционной системы. На этом этапе ядро может изменить режимы процессора, если пожелает, но это запрещает использование служб времени выполнения (если ядро снова не переключится обратно). [29] : разделы 2.3.2 и 2.3.4. Начиная с версии 3.15, ядро Linux поддерживает загрузку 64-битных ядер на 32-битных реализациях встроенного ПО UEFI, работающих на процессорах x86-64 , с поддержкой передачи обслуживания UEFI при загрузке UEFI. погрузчик по требованию. [30] Протокол передачи обслуживания UEFI дедуплицирует код инициализации UEFI между ядром и загрузчиками UEFI, оставляя инициализацию выполняться только загрузочной заглушкой UEFI ядра Linux . [31] [32]
В дополнение к стандартной схеме разделов диска ПК, в которой используется основная загрузочная запись (MBR), UEFI также работает со схемой разделов таблицы разделов GUID (GPT), которая свободна от многих ограничений MBR. В частности, ослаблены ограничения MBR на количество и размер разделов диска (до четырех основных разделов на диск и до 2 ТБ (2 × 2 40 байт ) на диск). [33] Более конкретно, GPT допускает максимальный размер диска и раздела 8 ЗиБ (8 × 2 70 байт) . [34] [35]
Поддержка GPT в Linux включается путем включения опции CONFIG_EFI_PARTITION(Поддержка разделов EFI GUID) во время настройки ядра. [36] Эта опция позволяет Linux распознавать и использовать GPT-диски после того, как встроенное ПО системы передает контроль над системой Linux.
Для обратной совместимости Linux может использовать GPT-диски в системах на базе BIOS как для хранения данных, так и для загрузки, поскольку и GRUB 2 , и Linux поддерживают GPT. Такая настройка обычно называется BIOS-GPT . [37] [ ненадежный источник? ] Поскольку GPT включает в себя защитную MBR, компьютер на базе BIOS может загружаться с диска GPT, используя загрузчик с поддержкой GPT, хранящийся в области загрузочного кода защитной MBR . [35] В случае GRUB такая конфигурация требует, чтобы загрузочный раздел BIOS для GRUB встраивал свой код второго этапа из-за отсутствия пробела после MBR в разделенных на GPT дисках (который берет на себя первичный заголовок GPT и Основная таблица разделов ). Обычно размер 1 МБ , глобальный уникальный идентификатор (GUID) этого раздела в схеме GPT — 21686148-6449-6E6F-744E-656564454649 и используется GRUB только в настройках BIOS-GPT. С точки зрения GRUB, в случае разделения MBR такого типа раздела не существует. Этот раздел не требуется, если система основана на UEFI, поскольку в этом случае встраивание кода второго этапа не требуется. [17] [35] [37]
Системы UEFI могут получать доступ к GPT-дискам и загружаться непосредственно с них, что позволяет Linux использовать методы загрузки UEFI. Загрузка Linux с GPT-дисков в системах UEFI предполагает создание системного раздела EFI (ESP), который содержит приложения UEFI, такие как загрузчики, ядра операционной системы и служебное программное обеспечение. [38] [39] [40] [ ненадежный источник? ] Такая установка обычно называется UEFI-GPT , при этом рекомендуется, чтобы ESP имел размер не менее 512 МБ и был отформатирован в файловой системе FAT32 для максимальной совместимости. [35] [37] [41] [ ненадежный источник? ]
В целях обратной совместимости некоторые реализации UEFI также поддерживают загрузку с дисков с разделами MBR через модуль поддержки совместимости (CSM), который обеспечивает совместимость с устаревшей BIOS. [42] В этом случае загрузка Linux в системах UEFI такая же, как и в устаревших системах на базе BIOS.
64-разрядные версии Windows Vista SP1 и более поздних версий, а также 32-разрядные версии Windows 8 , 8.1 и 10 могут загружаться с GPT-диска объемом более 2 ТБ .
EFI определяет два типа служб: службы загрузки и службы времени выполнения . Службы загрузки доступны только пока прошивка владеет платформой (т.е. до вызова ExitBootServices()), и к ним относятся текстовые и графические консоли на различных устройствах, а также шинные, блочные и файловые службы. Службы времени выполнения по-прежнему доступны во время работы операционной системы; они включают в себя такие службы, как дата, время и доступ к NVRAM .
Помимо загрузки ОС, 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 прошивке, используемой, среди прочего, в компьютерах Apple Macintosh на базе PowerPC и Sun Microsystems SPARC .
Некоторые драйверы EFI, зависящие от архитектуры (не байт-код EFI), для некоторых типов устройств могут иметь интерфейсы для использования ОС. Это позволяет ОС использовать EFI для драйверов для выполнения основных графических и сетевых функций до загрузки драйверов, специфичных для операционной системы, и в случае их загрузки.
В других случаях драйвером EFI могут быть драйверы файловой системы, позволяющие загрузку с дисковых томов других типов. Примеры включают efifs для 37 файловых систем (на основе кода GRUB2 ), [46] используемых Rufus для цепной загрузки NTFS ESP. [47]
Спецификация EFI 1.0 определила протокол UGA (универсальный графический адаптер) как способ поддержки графических функций. UEFI не включил UGA и заменил его GOP (протокол вывода графики) . [48]
В UEFI 2.1 определена «инфраструктура пользовательского интерфейса» (HII) для управления пользовательским вводом, локализованными строками, шрифтами и формами (в смысле HTML ). Они позволяют производителям оригинального оборудования (OEM) или независимым поставщикам BIOS (IBV) разрабатывать графические интерфейсы для конфигурации перед загрузкой.
Большинство ранних реализаций прошивки UEFI были консольными. Сегодня многие реализации встроенного ПО UEFI основаны на графическом интерфейсе.
Системный раздел EFI, часто сокращенно ESP, представляет собой раздел устройства хранения данных , который используется на компьютерах, соответствующих спецификации UEFI. Доступ к прошивке UEFI при включении компьютера сохраняет приложения UEFI и файлы, необходимые для запуска этих приложений, включая загрузчики операционной системы . Поддерживаемые схемы таблиц разделов включают MBR и GPT , а также тома El Torito на оптических дисках. [29] : раздел 2.6.2 Для использования в ESP UEFI определяет конкретную версию файловой системы FAT , которая поддерживается как часть спецификации UEFI и независимо от исходной спецификации FAT, включая файловые системы FAT32 , FAT16 и FAT12 . . [29] : раздел 12.3 [49] [50] [51] ESP также предоставляет место для загрузочного сектора в рамках обратной совместимости BIOS. [42]
В отличие от устаревшего BIOS ПК, UEFI не полагается на загрузочные сектора , а вместо этого определяет менеджер загрузки как часть спецификации UEFI. При включении компьютера менеджер загрузки проверяет конфигурацию загрузки и на основе своих настроек затем запускает указанный загрузчик ОС или ядро операционной системы (обычно загрузчик [52] ). Конфигурация загрузки определяется переменными, хранящимися в NVRAM , включая переменные, указывающие пути файловой системы к загрузчикам ОС или ядрам ОС.
Загрузчики ОС могут автоматически обнаруживаться с помощью UEFI, что позволяет легко загружать со съемных устройств, таких как USB-накопители . Это автоматическое обнаружение основано на стандартизированных путях к файлам загрузчика ОС, причем путь варьируется в зависимости от архитектуры компьютера . Формат пути к файлу определяется как <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI ; например, путь к файлу загрузчика ОС в системе x86-64 — \efi\boot\bootx64.efi , [29] и \efi\boot\bootaa64.efi в архитектуре ARM64.
Загрузка систем UEFI с дисков с разделами GPT обычно называется загрузкой UEFI-GPT . Несмотря на то, что спецификация UEFI требует полной поддержки таблиц разделов MBR, [29] некоторые реализации прошивки UEFI немедленно переключаются на загрузку CSM на основе BIOS в зависимости от типа таблицы разделов загрузочного диска, эффективно предотвращая загрузку UEFI с Системный раздел EFI на дисках с разделами MBR. [42] Такая схема загрузки обычно называется UEFI-MBR .
Диспетчер загрузки также часто имеет текстовый пользовательский интерфейс, позволяющий пользователю выбрать нужную ОС (или утилиту настройки) из списка доступных вариантов загрузки.
Чтобы обеспечить обратную совместимость, реализации встроенного ПО UEFI на компьютерах класса ПК могут поддерживать загрузку в устаревшем режиме BIOS с дисков, разделенных MBR, через модуль поддержки совместимости (CSM) , который обеспечивает совместимость с устаревшим BIOS. В этом сценарии загрузка выполняется так же, как и в устаревших системах на базе BIOS, игнорируя таблицу разделов и полагаясь на содержимое загрузочного сектора . [42]
Загрузка в стиле BIOS с дисков, разделенных MBR, обычно называется BIOS-MBR , независимо от того, выполняется ли она в системах UEFI или устаревших системах на базе BIOS. Кроме того, возможна загрузка устаревших систем на базе BIOS с GPT-дисков, и такая схема загрузки обычно называется BIOS-GPT .
Модуль поддержки совместимости позволяет использовать устаревшие операционные системы и некоторые устаревшие дополнительные ПЗУ , которые не поддерживают UEFI. [53] Он также обеспечивает требуемую функциональность устаревшего режима управления системой (SMM), называемую CompatibilitySmm , в качестве дополнения к функциям, предоставляемым UEFI SMM. Примером такой устаревшей функциональности SMM является обеспечение устаревшей поддержки USB для клавиатуры и мыши путем эмуляции их классических аналогов PS/2 . [53]
В ноябре 2017 года Intel объявила, что планирует прекратить поддержку CSM к 2020 году .
В июле 2022 года «Лаборатория Касперского» опубликовала информацию о рутките, предназначенном для последовательной загрузки вредоносного кода на компьютерах с чипсетом Intel H81 и модулем поддержки совместимости затронутых материнских плат. [55]
Спецификация UEFI включает поддержку загрузки по сети через среду Preboot eXecution Environment (PXE). Сетевые протоколы загрузки PXE включают интернет-протокол ( IPv4 и IPv6 ), протокол пользовательских дейтаграмм (UDP), протокол динамической конфигурации хоста (DHCP), тривиальный протокол передачи файлов (TFTP) и iSCSI . [29] [56]
Образы ОС можно удаленно хранить в сетях хранения данных (SAN), используя интерфейс малых компьютерных систем Интернета (iSCSI) и Fibre Channel over Ethernet (FCoE) в качестве поддерживаемых протоколов доступа к SAN. [29] [57] [58]
В версии 2.5 спецификации UEFI добавлена поддержка доступа к загрузочным образам через HTTP . [59]
Спецификация UEFI определяет протокол, известный как Secure Boot , который может защитить процесс загрузки, предотвращая загрузку драйверов UEFI или загрузчиков ОС, которые не подписаны приемлемой цифровой подписью . Механические детали того, как именно должны быть подписаны эти драйверы, не уточняются. [60] Когда включена безопасная загрузка, она первоначально переводится в режим «настройки», который позволяет записать в прошивку открытый ключ, известный как «ключ платформы» (PK). После записи ключа Secure Boot переходит в «пользовательский» режим, в котором прошивкой могут быть загружены только драйверы UEFI и загрузчики ОС, подписанные ключом платформы. Дополнительные «ключи обмена ключами» (KEK) могут быть добавлены в базу данных, хранящуюся в памяти, чтобы разрешить использование других сертификатов, но они все равно должны иметь соединение с частной частью ключа платформы. [61] Безопасную загрузку также можно перевести в «Пользовательский» режим, при котором в систему можно добавить дополнительные открытые ключи, не соответствующие закрытому ключу. [62]
Безопасная загрузка поддерживается Windows 8 и 8.1 , Windows Server 2012 и 2012 R2, Windows 10 , Windows Server 2016 , 2019 и 2022 , а также Windows 11 , VMware vSphere 6.5 [63] и рядом дистрибутивов Linux , включая Fedora (начиная с версии 18), openSUSE (начиная с версии 12.3), RHEL (начиная с версии 7), CentOS (начиная с версии 7 [64] ), Debian (начиная с версии 10), [65] , Ubuntu (начиная с версии 12.04.2) и Linux Mint ( начиная с версии 12.04.2) . начиная с версии 21.3). [66] [67][обновлять] По состоянию на январь 2024 года поддержка FreeBSD находится на стадии планирования. [68]
UEFI предоставляет среду оболочки , которую можно использовать для выполнения других приложений UEFI, включая загрузчики UEFI . [40] Помимо этого, команды, доступные в оболочке UEFI, можно использовать для получения различной другой информации о системе или прошивке, включая получение карты памяти ( memmap), изменение переменных менеджера загрузки ( bcfg), запуск программ разбиения на разделы ( diskpart), загрузку Драйверы UEFI и редактирование текстовых файлов ( edit). [69] [ ненадежный источник? ] [70] [71]
Исходный код оболочки UEFI можно загрузить из проекта Intel TianoCore UDK/EDK2. [72] Также доступен готовый ShellBinPkg. [73] Shell v2 лучше всего работает в системах UEFI 2.3+ и рекомендуется в этих системах вместо Shell v1. Shell v1 должен работать во всех системах UEFI. [69] [74] [75]
Методы, используемые для запуска оболочки UEFI, зависят от производителя и модели материнской платы системы . Некоторые из них уже предоставляют прямую возможность настройки прошивки для запуска, например, скомпилированную версию оболочки x86-64 необходимо сделать доступной как <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Некоторые другие системы имеют уже встроенную оболочку UEFI, которую можно запустить с помощью соответствующих комбинаций клавиш. [76] [ ненадежный источник? ] [77] Для других систем решением является либо создание соответствующего USB-накопителя, либо добавление вручную ( bcfg) параметра загрузки, связанного с скомпилированной версией оболочки. [71] [76] [78] [ ненадежный источник? ] [79] [ ненадежный источник? ]
Ниже приведен список команд , поддерживаемых оболочкой EFI. [70]
Расширения UEFI можно загружать практически с любого энергонезависимого запоминающего устройства, подключенного к компьютеру. Например, производитель оригинального оборудования (OEM) может распространять системы с системным разделом EFI на жестком диске, что добавит дополнительные функции к стандартной прошивке UEFI, хранящейся в ПЗУ материнской платы .
UEFI Capsule определяет интерфейс обновления прошивки для ОС, который позиционируется как современный и безопасный. [80] Windows 8 , Windows 8.1 , Windows 10 , [81] и Fwupd для Linux поддерживают UEFI Capsule.
Как и BIOS , UEFI инициализирует и тестирует аппаратные компоненты системы (например, обучение памяти, обучение каналу PCIe, обучение каналу USB), а затем загружает загрузчик с запоминающего устройства или через сетевое соединение . В системах x86 прошивка UEFI обычно хранится во флэш-чипе NOR материнской платы. [82]
Машины UEFI могут иметь один из следующих классов, которые использовались для облегчения перехода на UEFI: [83]
Начиная с процессоров Intel Core 10-го поколения, Intel больше не предоставляет Legacy Video BIOS для iGPU ( Intel Graphics Technology ). Для загрузки Legacy с этими процессорами требуется Legacy Video BIOS, который по-прежнему может предоставляться видеокартой. [ нужна цитата ]
Это первый этап загрузки UEFI, но ему может предшествовать двоичный код, специфичный для платформы. (например, Intel ME , AMD PSP , микрокод ЦП ). Он состоит из минимального кода, написанного на языке ассемблера для конкретной архитектуры. Он инициализирует временную память (часто кэш ЦП в виде ОЗУ или встроенную SRAM SoC, CAR) и служит программным корнем доверия системы с возможностью проверки PEI перед передачей.
Второй этап загрузки UEFI состоит из диспетчера с учетом зависимостей, который загружает и запускает модули PEI (PEIM) для выполнения задач ранней инициализации оборудования, таких как инициализация основной памяти и операции восстановления встроенного ПО. Кроме того, он отвечает за обнаружение текущего режима загрузки и обработку многих операций ACPI S3. В случае возобновления ACPI S3 он отвечает за восстановление многих аппаратных регистров в состояние перед спящим режимом. PEI также использует CAR.
Этот этап состоит из модулей C и диспетчера, учитывающего зависимости. Теперь, когда основная память доступна, процессор, набор микросхем, материнская плата и другие устройства ввода-вывода инициализируются в DXE и BDS.
BDS является частью DXE. [85] [86] На этом этапе инициализируются загрузочные устройства, драйверы UEFI или дополнительные ПЗУ устройств PCI выполняются в соответствии с конфигурацией системы и обрабатываются параметры загрузки.
Это этап между выбором загрузочного устройства и передачей ОС. На этом этапе можно войти в оболочку UEFI или выполнить приложение UEFI, например загрузчик ОС.
UEFI передает управление операционной системе (ОС) после выполнения ExitBootServices() . UEFI-совместимая ОС теперь отвечает за выход из служб загрузки, запуская прошивку для выгрузки всего ненужного кода и данных, оставляя только код/данные служб времени выполнения, например SMM и ACPI . [87] Типичная современная ОС предпочитает использовать собственные программы (например, драйверы ядра ) для управления аппаратными устройствами.
Если используется устаревшая ОС, CSM обработает этот вызов, гарантируя, что система совместима с ожиданиями устаревшего BIOS.
Реализация EFI от Intel — это Intel Platform Innovation Framework под кодовым названием Tiano . Tiano работает на процессорах Intel XScale , Itanium , x86-32 и x86-64 и является проприетарным программным обеспечением, хотя часть кода была выпущена под лицензией BSD или Eclipse Public License (EPL) как TianoCore EDK II . TianoCore можно использовать в качестве полезной нагрузки для coreboot . [88]
Реализация UEFI компанией Phoenix Technologies получила название SecureCore Technology (SCT). [89] Компания American Megatrends предлагает собственную реализацию прошивки UEFI, известную как Aptio, [90] тогда как Insyde Software предлагает InsydeH2O, [91] и Byosoft предлагает ByoCore.
В декабре 2018 года Microsoft выпустила версию с открытым исходным кодом своей реализации UEFI на базе TianoCore EDK2 из линейки Surface — Project Mu . [92]
Реализация UEFI API была введена в универсальный загрузчик ( Das U-Boot ) в 2017 году. [93] В дистрибутивах Linux с архитектурой ARMv8 для загрузки используется реализация U-Boot UEFI в сочетании с GNU GRUB (например, SUSE Linux [ 94] ), то же самое справедливо и для OpenBSD. [95] Для загрузки из iSCSI iPXE можно использовать как приложение UEFI, загружаемое с помощью U-Boot. [96]
Первые рабочие станции и серверы 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. [97] 5 апреля 2006 года Apple впервые выпустила Boot Camp , который создает диск с драйверами Windows и инструмент неразрушающего разбиения на разделы, позволяющий устанавливать Windows XP или Vista без переустановки Mac OS X (теперь macOS). Также было выпущено обновление прошивки, которое добавило совместимость с BIOS к реализации EFI. Последующие модели Macintosh поставлялись с более новой прошивкой. [98]
В 2005 году более миллиона систем Intel были поставлены с реализацией Intel UEFI. [99] [ не удалось проверить ] Новые мобильные, настольные и серверные продукты, использующие реализацию UEFI от Intel, начали поставляться в 2006 году. Например, платы, использующие набор микросхем Intel 945, используют реализацию встроенного ПО Intel UEFI.
С 2005 года EFI также реализуется на архитектурах, отличных от ПК, например, во встроенных системах на базе ядер XScale . [99]
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. [100]
В 2011 году крупные производители (такие как ASRock , Asus , Gigabyte и MSI ) выпустили несколько материнских плат, ориентированных на потребителя, с использованием чипсета Intel 6-й серии LGA 1155 и чипсетов AMD 9-й серии AM3+ с UEFI. [101]
С выпуском Windows 8 в октябре 2012 года сертификационные требования Microsoft теперь требуют, чтобы компьютеры имели встроенное ПО, реализующее спецификацию UEFI. Кроме того, если компьютер поддерживает функцию « Подключенный режим ожидания » в Windows 8 (которая позволяет устройствам управлять питанием, как у смартфонов , с почти мгновенным выходом из режима ожидания), то встроенное ПО не может содержать модуль поддержки совместимости ( ЦСМ). Таким образом, системы, поддерживающие Connected Standby, не способны загружать устаревшие операционные системы BIOS. [102] [103]
В октябре 2017 года Intel объявила, что к 2020 году откажется от поддержки устаревшего BIOS для ПК из всех своих продуктов в пользу UEFI Class 3. [104]
Операционная система, которую можно загрузить с (U)EFI, называется операционной системой с поддержкой (U)EFI, что определяется спецификацией (U)EFI. Здесь термин «загрузка с (U)EFI» означает непосредственную загрузку системы с использованием загрузчика операционной системы (U)EFI, хранящегося на любом устройстве хранения данных. Местоположение загрузчика операционной системы по умолчанию — , <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFIгде краткое имя типа машины может быть IA32, X64, или . [29] Некоторые поставщики операционных систем могут иметь собственные загрузчики. Они также могут изменить местоположение загрузки по умолчанию.IA64ARMAA64
Комплект разработки приложений EDK2 (EADK) позволяет использовать стандартные функции библиотеки C в приложениях UEFI. EADK можно бесплатно загрузить из проекта Intel TianoCore UDK/EDK2 SourceForge . Например, порт интерпретатора Python доступен как приложение UEFI с помощью EADK. [141] Начиная с UDK2015, разработка была перенесена на GitHub. [142]
Минималистичная программа на языке 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 "привет, мир \n " ); вернуть EFI_SUCCESS ; } Многочисленные активисты за цифровые права протестовали против UEFI. Рональд Г. Минних, соавтор coreboot , и Кори Доктороу , активист по защите цифровых прав, раскритиковали UEFI как попытку лишить пользователя возможности по-настоящему управлять компьютером. [143] [144] Это не решает давнюю проблему BIOS, связанную с необходимостью использования двух разных драйверов — одного для встроенного ПО и одного для операционной системы — для большинства аппаратных средств. [145]
Проект с открытым исходным кодом TianoCore также предоставляет UEFI. [146] В TianoCore отсутствуют специализированные драйверы, которые инициализируют функции набора микросхем, которые вместо этого предоставляются coreboot , одним из многих вариантов полезной нагрузки которого является TianoCore. Разработка coreboot требует сотрудничества производителей чипсетов для предоставления спецификаций, необходимых для разработки драйверов инициализации.
В 2011 году Microsoft объявила, что компьютеры, сертифицированные для работы с ее операционной системой Windows 8, должны поставляться с зарегистрированным открытым ключом Microsoft и включенной безопасной загрузкой. После этого объявления критики и сторонники свободного программного обеспечения/открытого исходного кода (включая Free Software Foundation ) обвинили компанию в попытке использовать функцию безопасной загрузки UEFI, чтобы помешать или полностью предотвратить установку альтернативных операционных систем, таких как Linux . Microsoft отрицает, что требование безопасной загрузки было предназначено для использования в качестве формы блокировки , и уточнила свои требования, заявив, что системы на базе x86, сертифицированные для Windows 8, должны позволять безопасной загрузке переходить в пользовательский режим или отключаться, но не в системах. с использованием архитектуры ARM . [62] [147] Windows 10 позволяет OEM-производителям решать, могут ли пользователи их систем x86 управлять безопасной загрузкой. [148]
Другие разработчики выразили обеспокоенность по поводу юридических и практических вопросов реализации поддержки безопасной загрузки в системах Linux в целом. Бывший разработчик Red Hat Мэтью Гарретт отметил, что условия Стандартной общественной лицензии GNU версии 3 могут препятствовать использованию GNU GRand Unified Bootloader без раскрытия разработчиком дистрибутива закрытого ключа (однако Фонд свободного программного обеспечения с тех пор уточнил свою позицию, заверив, что ответственность за предоставление ключей лежала на производителе оборудования), [149] [107] и что опытным пользователям также будет сложно создавать собственные ядра , которые могли бы работать с включенной безопасной загрузкой без их самоподписания. [147] Другие разработчики предположили, что можно предоставить подписанные сборки Linux с другим ключом, но отметили, что будет сложно убедить OEM-производителей поставлять свои компьютеры с необходимым ключом вместе с ключом Microsoft. [2]
В нескольких основных дистрибутивах Linux разработаны различные реализации безопасной загрузки. Сам Гаррет разработал минимальный загрузчик, известный как shim, который представляет собой предварительно скомпилированный подписанный загрузчик, позволяющий пользователю индивидуально доверять ключам, предоставляемым дистрибутивами Linux. [150] Ubuntu 12.10 использует более старую версию прокладки [ которая? ] предварительно настроен для использования с собственным ключом Canonical , который проверяет только загрузчик и позволяет загружать неподписанные ядра; разработчики считали, что практика подписания только загрузчика более осуществима, поскольку доверенное ядро эффективно защищает только пространство пользователя , а не предзагрузочное состояние, для которого Secure Boot предназначен для дополнительной защиты. Это также позволяет пользователям создавать свои собственные ядра и использовать собственные модули ядра без необходимости перенастройки системы. [107] [151] [152] Canonical также поддерживает собственный закрытый ключ для подписи установок Ubuntu, предварительно загруженных на сертифицированные OEM-компьютеры, на которых установлена операционная система, а также планирует обеспечить соблюдение требований безопасной загрузки, требуя как ключ и ключ Microsoft (по соображениям совместимости), которые должны быть включены в их прошивку. Fedora также использует прокладку, [ какую? ] , но требует, чтобы и ядро, и его модули также были подписаны. [151]
Спорным является вопрос о том, необходимо ли также подписывать ядро операционной системы и его модули; хотя спецификации UEFI этого не требуют, Microsoft утверждает, что их контрактные требования требуют этого, и что она оставляет за собой право отозвать любые сертификаты, используемые для подписи кода, который может быть использован для компрометации безопасности системы. [152] В Windows, если включена безопасная загрузка, все драйверы ядра должны иметь цифровую подпись; Драйверам, отличным от WHQL, может быть отказано в загрузке. В феврале 2013 года другой разработчик Red Hat попытался представить исправление для ядра Linux, которое позволило бы ему анализировать подпись Microsoft с использованием аутентичного кода с использованием главного ключа X.509, встроенного в PE -файлы, подписанные Microsoft. Однако это предложение подверглось критике со стороны создателя Linux Линуса Торвальдса , который напал на Red Hat за поддержку контроля Microsoft над инфраструктурой безопасной загрузки. [153]
26 марта 2013 года испанская группа разработчиков бесплатного программного обеспечения Hispalinux подала официальную жалобу в Европейскую комиссию , утверждая, что требования Microsoft по безопасной загрузке для OEM-систем являются «обструкционными» и антиконкурентными . [154]
На конференции Black Hat в августе 2013 года группа исследователей безопасности представила серию эксплойтов в реализациях UEFI конкретных поставщиков, которые можно использовать для использования Secure Boot. [155]
В августе 2016 года сообщалось, что два исследователя безопасности обнаружили ключ безопасности «золотой ключ», который Microsoft использует для подписи операционных систем. [156] Технически ключ не был раскрыт, однако был обнаружен пригодный для использования двоичный файл, подписанный ключом. Это позволяет любому программному обеспечению работать так, как будто оно действительно подписано Microsoft, и подвергает риску атаки руткитов и буткитов . Это также делает невозможным исправление ошибки, поскольку любое исправление может быть заменено (понижено) на (подписанный) пригодный для использования двоичный файл. Microsoft ответила заявлением, что уязвимость существует только в архитектуре ARM и устройствах Windows RT , и выпустила два патча; однако исправления не устраняют (и не могут) устранить уязвимость, для устранения которой потребуется замена ключей в прошивке конечного пользователя. [ нужна цитата ]
1 марта 2023 года исследователи из фирмы ESET Cybersecurity сообщили о «первом действующем бутките UEFI в обход UEFI Secure Boot» под названием «BlackLotus» в своих результатах публичного анализа, описывающих теорию, лежащую в основе его механики, использующую патчи, которые «не ( и не может) устранить уязвимость». [157] [158]
Многие дистрибутивы Linux теперь поддерживают UEFI Secure Boot, например RHEL (RHEL 7 и новее), CentOS (CentOS 7 и новее [159] ), Ubuntu , Fedora , Debian (Debian 10 и новее [160] ), OpenSUSE , SUSE Linux . [161]
Возросшая популярность прошивки UEFI в устройствах также привела к ряду технических проблем, в которых виноваты их соответствующие реализации. [162]
После выпуска Windows 8 в конце 2012 года было обнаружено, что некоторые модели компьютеров Lenovo с безопасной загрузкой имели встроенное ПО, которое было жестко закодировано и позволяло загружать только исполняемые файлы с именами « Windows Boot Manager » или « Red Hat Enterprise Linux », независимо от любых других параметр. [163] Другие проблемы возникли у нескольких моделей ноутбуков Toshiba с безопасной загрузкой, в которых отсутствовали определенные сертификаты, необходимые для правильной работы. [162]
В январе 2013 года была опубликована ошибка, связанная с реализацией UEFI на некоторых ноутбуках Samsung , из-за которой они блокировались после установки дистрибутива Linux в режиме UEFI. Хотя первоначально обвинялись в потенциальных конфликтах с модулем ядра, предназначенным для доступа к системным функциям ноутбуков Samsung (что также побудило сопровождающих ядра отключить модуль в системах UEFI в качестве меры безопасности), Мэтью Гарретт обнаружил, что ошибка на самом деле была вызвана сохранением слишком большого количества UEFI. переменные в память и что ошибка также может возникнуть в Windows при определенных условиях. В заключение он определил, что нарушивший модуль ядра вызвал запись дампов сообщений ядра в прошивку, тем самым вызвав ошибку. [44] [164] [165]
Вопрос: Какова связь между EFI и UEFI? О: Спецификация UEFI основана на спецификации EFI 1.10, опубликованной Intel, с исправлениями и изменениями, управляемыми Unified EFI Forum. Intel по-прежнему владеет авторскими правами на спецификацию EFI 1.10, но предоставила ее на Форум, чтобы Форум мог ее развивать. Будущих версий спецификации EFI не будет, но клиенты, получившие лицензию на нее, по-прежнему смогут использовать ее в соответствии с условиями лицензии Intel. Лицензия на унифицированную спецификацию EFI исходит от форума, а не от Intel.
Файловая система, поддерживаемая расширяемым интерфейсом встроенного ПО, основана на файловой системе FAT. EFI определяет конкретную версию FAT, которая явно документирована и доступна для тестирования. Соответствие спецификации EFI и связанным с ней справочным документам — единственное определение FAT, которое необходимо реализовать для поддержки EFI. Чтобы отличить файловую систему EFI от чистой FAT, был определен новый тип файловой системы разделов.
System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby... Платформы должны быть UEFI класса три (определение см. в разделе UEFI Industry Group, Оценка UEFI с использованием коммерческих платформ и решений, версия 0.3) без модуля поддержки совместимости. установленный или устанавливаемый. Эмуляция BIOS и устаревшая загрузка ПК/AT должны быть отключены.
Microsoft определила, что поставщики не будут заинтересованы в производстве собственной 32-битной прошивки UEFI из-за текущего состояния основных 64-битных вычислений и стоимости платформы. Поэтому Microsoft изначально не предоставляла поддержку 32-битных реализаций UEFI.
