Unified Extensible Firmware Interface ( UEFI , / ˈjuːɪf aɪ / или как аббревиатура) [c] — это спецификация , которая определяет архитектуру для прошивки платформы, используемой для загрузки оборудования компьютера, и ее интерфейс для взаимодействия с операционной системой . Примерами прошивки , реализующей спецификацию, являются AMI Aptio , Phoenix SecureCore , TianoCore EDK II , InsydeH2O .
UEFI заменяет BIOS , который присутствовал в загрузочном ПЗУ всех персональных компьютеров , совместимых с IBM PC , [4] [5], хотя он может обеспечить обратную совместимость с BIOS с помощью загрузки CSM. В отличие от своего предшественника BIOS, который является фактическим стандартом, изначально созданным IBM как проприетарное программное обеспечение, UEFI является открытым стандартом, поддерживаемым отраслевым консорциумом .
Intel разработала оригинальную спецификацию Extensible Firmware Interface ( EFI ). Последняя версия EFI от Intel была 1.10, выпущенная в 2005 году. Последующие версии были разработаны как UEFI Форумом Unified EFI .
UEFI не зависит от платформы и языка программирования, но для эталонной реализации TianoCore EDKII используется язык C.
Первоначальная мотивация для EFI возникла во время ранней разработки первых систем Intel–HP Itanium в середине 1990-х годов. Ограничения BIOS (такие как 16-битный реальный режим , 1 МБ адресуемой памяти, [6] программирование на языке ассемблера и аппаратное обеспечение PC AT ) стали слишком ограничивающими для более крупных серверных платформ, на которые ориентировался Itanium. [7] Усилия по решению этих проблем начались в 1998 году и изначально назывались Intel Boot Initiative . [8] Позднее он был переименован в Extensible Firmware Interface (EFI). [9] [10]
Первая реализация UEFI с открытым исходным кодом , Tiano, была выпущена Intel в 2004 году. С тех пор Tiano был заменен EDK [11] и EDK II [12] и в настоящее время поддерживается сообществом TianoCore. [13]
В июле 2005 года Intel прекратила разработку спецификации EFI на версии 1.10 и передала ее на Форум Unified EFI , который разработал спецификацию как Unified Extensible Firmware Interface (UEFI). Первоначальная спецификация EFI остается собственностью Intel, которая предоставляет эксклюзивные лицензии на продукты на основе EFI, но спецификация UEFI принадлежит Форуму UEFI. [7] [14]
Версия 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 EDK II, используемое в продуктах Microsoft Surface и Hyper-V . Проект продвигает идею прошивки как услуги . [15]
Последняя спецификация UEFI, версия 2.10, была опубликована в августе 2022 года. [16]
Интерфейс, определенный спецификацией EFI, включает таблицы данных, содержащие информацию о платформе, а также службы загрузки и выполнения, доступные загрузчику ОС и ОС. Прошивка UEFI обеспечивает несколько технических преимуществ по сравнению с BIOS: [17]
С помощью UEFI можно хранить ключи продукта для операционных систем, таких как Windows, в прошивке UEFI устройства. [20] [21] [22] UEFI требуется для устройств, поставляемых с Windows 8 [23] [24] и выше.
Операционные системы также могут получить доступ к данным конфигурации UEFI. [25]
Начиная с версии 2.5, существуют привязки процессоров для Itanium, x86, x86-64, ARM (AArch32) и ARM64 (AArch64). [26] Поддерживаются только процессоры с прямым порядком байтов . [27] Неофициальная поддержка UEFI находится в стадии разработки для POWERPC64 путем внедрения TianoCore поверх OPAL, [28] уровня абстракции OpenPOWER, работающего в режиме прямого порядка байтов. [29] Аналогичные проекты существуют для MIPS [30] и RISC-V . [31] Начиная с UEFI 2.7, привязки процессоров RISC-V были официально установлены для 32-, 64- и 128-битных режимов. [32]
Стандартный BIOS ПК ограничен 16-битным режимом процессора и 1 МБ адресуемого пространства памяти, что является результатом разработки на основе IBM 5150 , которая использовала 16-битный процессор Intel 8088. [7] [33] Для сравнения, режим процессора в среде UEFI может быть как 32-битным ( IA-32 , AArch32), так и 64-битным ( x86-64 , Itanium и AArch64). [7] [34] 64-битные реализации прошивки UEFI поддерживают длинный режим , который позволяет приложениям в среде предзагрузки использовать 64-битную адресацию для получения прямого доступа ко всей памяти машины. [35]
UEFI требует, чтобы загрузчик (или ядро) прошивки и операционной системы были согласованы по размеру; то есть 64-разрядная реализация прошивки UEFI может загружать только загрузчик или ядро 64-разрядной операционной системы (ОС) (если только не используется устаревшая загрузка на основе CSM ), и то же самое относится к 32-разрядной. После того, как система переходит от служб загрузки к службам времени выполнения , ядро операционной системы берет на себя управление. В этот момент ядро может изменить режимы процессора, если оно того пожелает, но это запрещает использование служб времени выполнения (если только ядро не переключится обратно). [36] : разделы 2.3.2 и 2.3.4 Начиная с версии 3.15, ядро Linux поддерживает загрузку 64-разрядных ядер на 32-разрядных реализациях прошивки UEFI, работающих на процессорах x86-64 , с поддержкой передачи UEFI от загрузчика UEFI в качестве требования. [37] Протокол передачи UEFI дедуплицирует код инициализации UEFI между ядром и загрузчиками UEFI, оставляя инициализацию, выполняемую только загрузочной заглушкой UEFI ядра Linux . [38] [39]
В дополнение к стандартной схеме разделов диска ПК, которая использует главную загрузочную запись (MBR), UEFI также работает со схемой разделов GUID Partition Table (GPT), которая свободна от многих ограничений MBR. В частности, ограничения MBR по количеству и размеру разделов диска (до четырех основных разделов на диск и до 2 ТБ (2 × 2 40 байт ) на диск) смягчены. [40] Более конкретно, GPT допускает максимальный размер диска и раздела 8 ЗиБ (8 × 2 70 байт) . [41] [42]
Поддержка GPT в Linux включается путем включения опции CONFIG_EFI_PARTITION(EFI GUID Partition Support) во время настройки ядра. [43] Эта опция позволяет Linux распознавать и использовать диски GPT после того, как системная прошивка передает управление системой Linux.
Для обратной совместимости Linux может использовать диски GPT в системах на базе BIOS как для хранения данных, так и для загрузки, поскольку и GRUB 2 , и Linux поддерживают GPT. Такая настройка обычно называется BIOS-GPT . [44] [ ненадежный источник? ] Поскольку GPT включает в себя защитную MBR, компьютер на базе BIOS может загружаться с диска GPT, используя загрузчик, поддерживающий GPT, хранящийся в области кода начальной загрузки защитной MBR . [42] В случае GRUB такая конфигурация требует загрузочного раздела BIOS , чтобы GRUB встроил свой код второго этапа из-за отсутствия промежутка после MBR в дисках, разделенных на разделы GPT (который занят первичным заголовком и первичной таблицей разделов GPT ). Обычно размером 1 МБ , этот раздел имеет глобальный уникальный идентификатор (GUID) в схеме GPT 21686148-6449-6E6F-744E-656564454649 и используется GRUB только в настройках BIOS-GPT. С точки зрения GRUB, такого типа раздела не существует в случае разбиения на разделы MBR. Этот раздел не требуется, если система основана на UEFI, поскольку в этом случае не требуется внедрение кода второго этапа. [18] [42] [44]
Системы UEFI могут получать доступ к дискам GPT и загружаться напрямую с них, что позволяет Linux использовать методы загрузки UEFI. Загрузка Linux с дисков GPT на системах UEFI подразумевает создание системного раздела EFI (ESP), который содержит приложения UEFI, такие как загрузчики, ядра операционной системы и служебное программное обеспечение. [45] [46] [47] [ ненадежный источник? ] Такая настройка обычно называется UEFI-GPT , в то время как ESP рекомендуется иметь размер не менее 512 МБ и отформатировать в файловой системе FAT32 для максимальной совместимости. [42] [44] [48] [ ненадежный источник? ]
Для обеспечения обратной совместимости некоторые реализации UEFI также поддерживают загрузку с дисков с разделами MBR через модуль поддержки совместимости (CSM), который обеспечивает совместимость с устаревшей версией BIOS. [49] В этом случае загрузка Linux на системах UEFI такая же, как и на устаревших системах на основе BIOS.
Некоторые практики и форматы данных EFI копируют практики и форматы данных Microsoft Windows . [50] [51]
64-разрядные версии Windows Vista SP1 и более поздние версии, а также 64-разрядные версии Windows 8 , 8.1 , 10 и 11 могут загружаться с GPT-диска размером более 2 ТБ .
EFI определяет два типа служб: службы загрузки и службы времени выполнения . Службы загрузки доступны только пока прошивка владеет платформой (т. е. до ExitBootServices()вызова), и они включают текстовые и графические консоли на различных устройствах, а также службы шины, блока и файла. Службы времени выполнения по-прежнему доступны во время работы операционной системы; они включают такие службы, как дата, время и доступ к NVRAM .
Помимо загрузки ОС, UEFI может запускать приложения UEFI , которые находятся в виде файлов на системном разделе EFI . Они могут быть запущены из UEFI Shell, менеджером загрузки прошивки или другими приложениями 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 и Sun Microsystems SPARC на базе PowerPC , среди прочих.
Некоторые архитектурно-специфичные (не EFI Byte Code) драйверы EFI для некоторых типов устройств могут иметь интерфейсы для использования ОС. Это позволяет ОС полагаться на EFI для драйверов, чтобы выполнять основные графические и сетевые функции до и после загрузки драйверов, специфичных для операционной системы.
В других случаях драйвер EFI может быть драйвером файловой системы, который позволяет загружать с других типов томов диска. Примеры включают efif для 37 файловых систем (на основе кода GRUB2 ), [55] используемый Rufus для цепной загрузки NTFS ESP. [56]
Спецификация EFI 1.0 определила протокол UGA (Universal Graphic Adapter) как способ поддержки графических функций. UEFI не включал UGA и заменил его на GOP (Graphics Output Protocol) . [57]
UEFI 2.1 определила «Инфраструктуру интерфейса пользователя» (HII) для управления пользовательским вводом, локализованными строками, шрифтами и формами (в смысле HTML ). Они позволяют производителям оригинального оборудования (OEM) или независимым поставщикам BIOS (IBV) разрабатывать графические интерфейсы для предзагрузочной конфигурации. UEFI по умолчанию использует UTF-16 для кодирования строк.
Большинство ранних реализаций прошивки UEFI были консольными. Сегодня многие реализации прошивки UEFI основаны на графическом интерфейсе.
Системный раздел EFI, часто сокращенно ESP, представляет собой раздел устройства хранения данных , который используется в компьютерах, соответствующих спецификации UEFI. Доступ к которому осуществляется прошивкой UEFI при включении компьютера, он хранит приложения UEFI и файлы, необходимые этим приложениям для запуска, включая загрузчики операционной системы . Поддерживаемые схемы таблиц разделов включают MBR и GPT , а также тома El Torito на оптических дисках. [36] : раздел 2.6.2 Для использования на ESP UEFI определяет определенную версию файловой системы FAT , которая поддерживается как часть спецификации UEFI и независимо от исходной спецификации FAT, охватывая файловые системы FAT32 , FAT16 и FAT12 . [36] : раздел 12.3 [58] [59] [60] ESP также предоставляет место для загрузочного сектора в рамках обратной совместимости BIOS. [49]
В отличие от устаревшего BIOS ПК, UEFI не полагается на загрузочные секторы , определяя вместо этого менеджер загрузки как часть спецификации UEFI. Когда компьютер включается, менеджер загрузки проверяет конфигурацию загрузки и на основе ее настроек затем выполняет указанный загрузчик ОС или ядро операционной системы (обычно загрузчик [61] ). Конфигурация загрузки определяется переменными, хранящимися в NVRAM , включая переменные, которые указывают пути файловой системы к загрузчикам ОС или ядрам ОС.
Загрузчики ОС могут автоматически определяться UEFI, что позволяет легко загружать систему со съемных устройств, таких как USB-флеш-накопители . Это автоматическое определение основано на стандартизированных путях к файлам загрузчика ОС, причем путь варьируется в зависимости от архитектуры компьютера . Формат пути к файлу определяется как <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI ; например, путь к файлу загрузчика ОС в системе x86-64 — \efi\boot\bootx64.efi , [36] и \efi\boot\bootaa64.efi в архитектуре ARM64.
Загрузка систем UEFI с дисков, разбитых на разделы GPT, обычно называется загрузкой UEFI-GPT . Несмотря на то, что спецификация UEFI требует полной поддержки таблиц разделов MBR, [36] некоторые реализации прошивки UEFI немедленно переключаются на загрузку CSM на основе BIOS в зависимости от типа таблицы разделов загрузочного диска, фактически предотвращая загрузку UEFI с системного раздела EFI на дисках, разбитых на разделы MBR. [49] Такая схема загрузки обычно называется UEFI-MBR .
Менеджер загрузки также часто имеет текстовый пользовательский интерфейс, позволяющий пользователю выбрать нужную ОС (или утилиту настройки) из списка доступных вариантов загрузки.
Для обеспечения обратной совместимости реализации прошивки UEFI на компьютерах класса ПК могут поддерживать загрузку в устаревшем режиме BIOS с дисков с разделами MBR через модуль поддержки совместимости (CSM), который обеспечивает совместимость с устаревшим BIOS. В этом сценарии загрузка выполняется так же, как и в устаревших системах на базе BIOS, игнорируя таблицу разделов и полагаясь на содержимое загрузочного сектора . [49]
Загрузка в стиле BIOS с дисков, разбитых на разделы MBR, обычно называется BIOS-MBR , независимо от того, выполняется ли она на UEFI или устаревших системах на базе BIOS. Кроме того, загрузка устаревших систем на базе BIOS с дисков GPT также возможна, и такая схема загрузки обычно называется BIOS-GPT .
Модуль поддержки совместимости позволяет использовать устаревшие операционные системы и некоторые устаревшие дополнительные ПЗУ , которые не поддерживают UEFI. [62] Он также предоставляет требуемую устаревшую функциональность System Management Mode (SMM), называемую CompatibilitySmm , в качестве дополнения к функциям, предоставляемым UEFI SMM. Примером такой устаревшей функциональности SMM является предоставление устаревшей поддержки USB для клавиатуры и мыши путем эмуляции их классических аналогов PS/2 . [62]
В ноябре 2017 года Intel объявила, что планирует прекратить поддержку CSM для клиентских платформ к 2020 году. [63]
В июле 2022 года «Лаборатория Касперского» опубликовала информацию о рутките, предназначенном для последовательной загрузки вредоносного кода на машины, использующие чипсет Intel H81 и модуль поддержки совместимости уязвимых материнских плат. [64]
В августе 2023 года Intel объявила, что планирует прекратить поддержку CSM для серверных платформ к 2024 году. [65]
На сегодняшний день все компьютеры на базе платформ Intel больше не поддерживают CSM.
Спецификация UEFI включает поддержку загрузки по сети через Preboot eXecution Environment (PXE). Сетевые протоколы загрузки PXE включают в себя Интернет-протокол ( IPv4 и IPv6 ), протокол пользовательских датаграмм (UDP), протокол динамической конфигурации хоста (DHCP), протокол Trivial File Transfer Protocol (TFTP) и iSCSI . [36] [66]
Образы ОС могут храниться удаленно в сетях хранения данных (SAN) с использованием интерфейсов малых вычислительных систем Интернета (iSCSI) и Fibre Channel over Ethernet (FCoE) в качестве поддерживаемых протоколов для доступа к сетям SAN. [36] [67] [68]
Версия 2.5 спецификации UEFI добавляет поддержку доступа к загрузочным образам по HTTP . [69]
Спецификация UEFI определяет протокол, известный как Secure Boot , который может защитить процесс загрузки, предотвращая загрузку драйверов UEFI или загрузчиков ОС, которые не подписаны приемлемой цифровой подписью . Механические детали того, как именно должны быть подписаны эти драйверы, не указаны. [70] Когда включена Secure Boot, она изначально переводится в режим «настройки», который позволяет записать в прошивку открытый ключ, известный как «ключ платформы» (PK). После записи ключа Secure Boot переходит в режим «Пользователь», в котором прошивкой могут быть загружены только драйверы UEFI и загрузчики ОС, подписанные ключом платформы. Дополнительные «ключи обмена ключами» (KEK) могут быть добавлены в базу данных, хранящуюся в памяти, чтобы разрешить использование других сертификатов, но они все равно должны иметь соединение с закрытой частью ключа платформы. [71] Secure Boot также может быть переведен в режим «Пользовательский», в котором в систему могут быть добавлены дополнительные открытые ключи, не соответствующие закрытому ключу. [72]
Secure Boot поддерживается Windows 8 и 8.1 , Windows Server 2012 и 2012 R2, Windows 10 , Windows Server 2016 , 2019 и 2022 , а также Windows 11 , VMware vSphere 6.5 [73] и рядом дистрибутивов Linux , включая Fedora (с версии 18), openSUSE (с версии 12.3), RHEL (с версии 7), CentOS (с версии 7 [74] ), Debian (с версии 10), [75] Ubuntu (с версии 12.04.2), Linux Mint (с версии 21.3), [76] [77] и AlmaLinux OS (с версии 8.4 [78] ). По состоянию на январь 2024 года [обновлять]поддержка FreeBSD находится на стадии планирования. [79]
UEFI предоставляет среду оболочки , которую можно использовать для выполнения других приложений UEFI, включая загрузчики UEFI . [47] Помимо этого, команды, доступные в оболочке UEFI, можно использовать для получения различной другой информации о системе или прошивке, включая получение карты памяти ( memmap), изменение переменных менеджера загрузки ( bcfg), запуск программ разбиения на разделы ( diskpart), загрузку драйверов UEFI и редактирование текстовых файлов ( edit). [80] [ ненадежный источник? ] [81] [82]
Исходный код для оболочки UEFI можно загрузить из проекта Intel TianoCore UDK/EDK2. [83] Также доступен предварительно собранный ShellBinPkg. [84] Shell v2 лучше всего работает в системах UEFI 2.3+ и рекомендуется вместо Shell v1 в этих системах. Shell v1 должен работать во всех системах UEFI. [80] [85] [86]
Методы, используемые для запуска оболочки UEFI, зависят от производителя и модели материнской платы системы . Некоторые из них уже предоставляют прямую опцию в настройке прошивки для запуска, например, скомпилированная версия оболочки x86-64 должна быть доступна как <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Некоторые другие системы имеют уже встроенную оболочку UEFI, которую можно запустить с помощью соответствующих комбинаций клавиш. [87] [ ненадежный источник? ] [88] Для других систем решением является либо создание соответствующего USB-накопителя, либо добавление вручную ( bcfg) параметра загрузки, связанного со скомпилированной версией оболочки. [82] [87] [89] [ ненадежный источник? ] [90] [ ненадежный источник? ]
Ниже приведен список команд, поддерживаемых оболочкой EFI. [81]
Расширения UEFI можно загрузить практически с любого энергонезависимого устройства хранения данных, подключенного к компьютеру. Например, производитель оригинального оборудования (OEM) может распространять системы с системным разделом EFI на жестком диске, что добавит дополнительные функции к стандартной прошивке UEFI, хранящейся в ПЗУ материнской платы .
UEFI Capsule определяет интерфейс обновления прошивки ОС, позиционируемый как современный и безопасный. [91] Windows 8 , Windows 8.1 , Windows 10 , [92] и Fwupd для Linux поддерживают UEFI Capsule.
Как и BIOS , UEFI инициализирует и тестирует компоненты системного оборудования (например, обучение памяти, обучение PCIe-соединения, обучение USB-соединения на типичных системах x86), а затем загружает загрузчик с запоминающего устройства или через сетевое соединение . В системах x86 прошивка UEFI обычно хранится во флэш-чипе NOR материнской платы. [93] [94] В некоторых устройствах Android на базе ARM загрузчик UEFI хранится во флэш-памяти eUFS .
Машины UEFI могут иметь один из следующих классов, которые использовались для облегчения перехода на UEFI: [95]
Начиная с 10-го поколения Intel Core, Intel больше не предоставляет Legacy Video BIOS для iGPU ( технология графики Intel ). Устаревшая загрузка с этими процессорами требует Legacy Video BIOS, который по-прежнему может быть предоставлен видеокартой. [ необходима цитата ]
Это первый этап загрузки UEFI, но ему может предшествовать специфичный для платформы двоичный код. (например, Intel ME , AMD PSP , микрокод CPU ). Он состоит из минимального кода, написанного на языке ассемблера для определенной архитектуры. Он инициализирует временную память (часто кэш CPU как RAM или SoC on-chip SRAM, CAR) и служит корнем доверия программного обеспечения системы с возможностью проверки PEI перед передачей.
Второй этап загрузки UEFI состоит из диспетчера зависимостей, который загружает и запускает модули PEI (PEIM) для обработки задач ранней инициализации оборудования, таких как инициализация основной памяти (инициализация контроллера памяти и DRAM ) и операции восстановления прошивки. Кроме того, он отвечает за обнаружение текущего режима загрузки и обработку многих операций ACPI S3. В случае возобновления ACPI S3 он отвечает за восстановление многих регистров оборудования до состояния перед сном. PEI также использует CAR. Инициализация на этом этапе включает создание структур данных в памяти и установку значений по умолчанию в этих структурах. [97]
Этот этап состоит из модулей C и диспетчера, осознающего зависимости. Теперь, когда основная память доступна, ЦП, чипсет, материнская плата и другие устройства ввода-вывода инициализируются в DXE и BDS. Инициализация на этом этапе включает назначение путей устройств EFI оборудованию, подключенному к материнской плате, и передачу данных конфигурации оборудованию. [98]
BDS является частью DXE. [99] [100] На этом этапе инициализируются загрузочные устройства, выполняются драйверы UEFI или дополнительные ПЗУ устройств PCI в соответствии с конфигурацией системы, а также обрабатываются параметры загрузки.
Это этап между выбором загрузочного устройства и передачей управления ОС. На этом этапе можно войти в оболочку UEFI или выполнить приложение UEFI, например, загрузчик ОС.
UEFI передает управление операционной системе (ОС) после выполнения ExitBootServices() . Теперь совместимая с UEFI ОС отвечает за выход из служб загрузки, запуская прошивку для выгрузки всего ненужного кода и данных, оставляя только код/данные служб времени выполнения, например SMM и ACPI . [101] Типичная современная ОС предпочитает использовать собственные программы (например, драйверы ядра ) для управления аппаратными устройствами.
При использовании устаревшей ОС CSM обработает этот вызов, обеспечив совместимость системы с ожиданиями устаревшей BIOS.
Реализация 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 . [102]
Реализация UEFI компанией Phoenix Technologies носит название SecureCore Technology (SCT). [103] American Megatrends предлагает собственную реализацию прошивки UEFI, известную как Aptio, [104] в то время как Insyde Software предлагает InsydeH2O, [105] а Byosoft предлагает ByoCore.
В декабре 2018 года Microsoft выпустила версию с открытым исходным кодом своей реализации UEFI на базе TianoCore EDK2 из линейки Surface , Project Mu . [106]
Реализация UEFI API была введена в универсальный загрузчик ( Das U-Boot ) в 2017 году. [107] В дистрибутивах Linux на архитектуре ARMv8 для загрузки используется реализация U-Boot UEFI в сочетании с GNU GRUB (например, SUSE Linux [108] ), то же самое справедливо и для OpenBSD. [109] Для загрузки с iSCSI iPXE можно использовать как приложение UEFI, загружаемое U-Boot. [110]
Первые рабочие станции и серверы Intel на базе процессоров Itanium , выпущенные в 2000 году, реализовали EFI 1.02.
Первые системы Itanium 2 компании Hewlett-Packard , выпущенные в 2002 году, реализовали EFI 1.10; они могли загружать Windows , Linux , FreeBSD и HP-UX ; OpenVMS добавила возможность UEFI в июне 2003 года.
В январе 2006 года Apple Inc. выпустила свои первые компьютеры Macintosh на базе Intel . Эти системы использовали EFI вместо Open Firmware , которая использовалась в предыдущих системах на базе PowerPC. [111] 5 апреля 2006 года Apple впервые выпустила Boot Camp , который создает диск с драйверами Windows и неразрушающий инструмент разбиения на разделы, позволяющий устанавливать Windows XP или Vista без необходимости переустановки Mac OS X (теперь macOS). Также было выпущено обновление прошивки, которое добавило совместимость BIOS с ее реализацией EFI. Последующие модели Macintosh поставлялись с более новой прошивкой. [112]
В 2005 году было поставлено более миллиона систем Intel с реализацией UEFI от Intel. [113] [ проверка не пройдена ] Новые мобильные, настольные и серверные продукты, использующие реализацию UEFI от Intel, начали поставляться в 2006 году. Например, платы, использующие серию чипсетов Intel 945, используют реализацию прошивки UEFI от Intel.
С 2005 года EFI также был реализован на архитектурах, отличных от ПК, таких как встроенные системы на основе ядер XScale . [113]
EDK (EFI Developer Kit) включает в себя цель NT32, которая позволяет запускать прошивку EFI и приложения EFI в приложении Windows . Но прямой доступ к оборудованию EDK NT32 не допускается. Это означает, что только подмножество приложений EFI и драйверов может быть выполнено целью EDK NT32.
В 2008 году больше систем x86-64 приняли UEFI. Хотя многие из этих систем по-прежнему позволяют загружать только ОС на базе BIOS через Compatibility Support Module (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. [114]
В 2011 году основные поставщики (такие как ASRock , Asus , Gigabyte и MSI ) выпустили несколько ориентированных на потребителя материнских плат с использованием чипсета Intel 6-й серии LGA 1155 и чипсетов AMD 9-й серии AM3+ с UEFI. [115]
С выпуском Windows 8 в октябре 2012 года требования сертификации Microsoft теперь требуют, чтобы компьютеры включали прошивку, реализующую спецификацию UEFI. Кроме того, если компьютер поддерживает функцию « Connected Standby » Windows 8 (которая позволяет устройствам иметь управление питанием, сопоставимое со смартфонами , с почти мгновенным возвратом из режима ожидания), то прошивка не может содержать модуль поддержки совместимости (CSM). Таким образом, системы, поддерживающие Connected Standby, не могут загружать устаревшие операционные системы BIOS. [116] [117]
В октябре 2017 года компания Intel объявила, что к 2020 году она прекратит поддержку устаревшей версии BIOS для всех своих продуктов в пользу UEFI Class 3. [118] К 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. [36] Некоторые поставщики операционных систем могут иметь собственные загрузчики. Они также могут изменять расположение загрузки по умолчанию.
EDK2 Application Development Kit (EADK) позволяет использовать стандартные функции библиотеки C в приложениях UEFI. EADK можно бесплатно загрузить из проекта Intel TianoCore UDK / EDK2 SourceForge . Например, порт интерпретатора Python становится доступным как приложение UEFI с помощью EADK. [156] Разработка перешла на GitHub с UDK2015. [157]
Минималистичная программа « Hello, World » на языке C, написанная с использованием EADK, выглядит так же, как и ее обычный аналог на языке C :
#include <Uefi.h> #include <Библиотека/UefiLib.h> #include <Библиотека/ShellCEntryLib.h> EFI_STATUS EFIAPI ShellAppMain ( IN UINTN Argc , IN CHAR16 ** Argv ) { Print ( L "привет, мир \n " ); return EFI_SUCCESS ; } Многочисленные активисты по защите цифровых прав протестовали против UEFI. Рональд Г. Минних, соавтор coreboot , и Кори Доктороу , активист по защите цифровых прав, критиковали UEFI как попытку лишить пользователя возможности по-настоящему управлять компьютером. [158] [159] Он не решает давние проблемы BIOS, требующие двух разных драйверов — одного для прошивки и одного для операционной системы — для большинства аппаратных средств. [160]
Проект с открытым исходным кодом TianoCore также предоставляет UEFI. [161] TianoCore не имеет специализированных драйверов, которые инициализируют функции чипсета, вместо этого они предоставляются coreboot , из которых TianoCore является одним из многих вариантов полезной нагрузки. Разработка coreboot требует сотрудничества с производителями чипсетов для предоставления спецификаций, необходимых для разработки драйверов инициализации.
В 2011 году Microsoft объявила, что компьютеры, сертифицированные для работы с ее операционной системой Windows 8, должны поставляться с зарегистрированным открытым ключом Microsoft и включенной безопасной загрузкой, что подразумевает, что использование UEFI является обязательным требованием для этих устройств. [162] [163] После этого объявления компания была обвинена критиками и сторонниками свободного программного обеспечения/открытого исходного кода (включая Free Software Foundation ) в попытке использовать функционал безопасной загрузки UEFI для воспрепятствования или прямого предотвращения установки альтернативных операционных систем, таких как Linux . Microsoft отрицала, что требование безопасной загрузки было призвано служить формой блокировки , и разъяснила свои требования, заявив, что системы на базе x86, сертифицированные для Windows 8, должны позволять безопасной загрузке входить в пользовательский режим или быть отключенной, но не в системах, использующих архитектуру ARM . [72] [164] Windows 10 позволяет OEM-производителям решать, могут ли пользователи их систем x86 управлять безопасной загрузкой. [165]
Другие разработчики выразили обеспокоенность по поводу юридических и практических вопросов реализации поддержки Secure Boot в системах Linux в целом. Бывший разработчик Red Hat Мэтью Гарретт отметил, что условия в GNU General Public License версии 3 могут помешать использованию GNU GRand Unified Bootloader без раскрытия разработчиком дистрибутива закрытого ключа (однако Free Software Foundation с тех пор разъяснил свою позицию, заверив, что ответственность за предоставление ключей лежит на производителе оборудования), [166] [121] и что также будет сложно для продвинутых пользователей создавать собственные ядра , которые могли бы работать с включенной Secure Boot без их самостоятельной подписи. [164] Другие разработчики предположили, что могут быть предоставлены подписанные сборки Linux с другим ключом, но отметили, что будет сложно убедить OEM-производителей поставлять свои компьютеры с требуемым ключом вместе с ключом Microsoft. [5]
Несколько основных дистрибутивов Linux разработали различные реализации для Secure Boot. Сам Гарретт разработал минимальный загрузчик, известный как shim, который представляет собой предварительно скомпилированный, подписанный загрузчик, позволяющий пользователю индивидуально доверять ключам, предоставляемым дистрибутивами Linux. [167] Ubuntu 12.10 использует старую версию shim [ which? ], предварительно настроенную для использования с собственным ключом Canonical , который проверяет только загрузчик и позволяет загружать неподписанные ядра; разработчики считали, что практика подписания только загрузчика более осуществима, поскольку доверенное ядро эффективно для защиты только пространства пользователя , а не состояния перед загрузкой, для которого Secure Boot предназначен для добавления защиты. Это также позволяет пользователям создавать свои собственные ядра и использовать пользовательские модули ядра без необходимости перенастраивать систему. [121] [168] [169] Canonical также поддерживает свой собственный закрытый ключ для подписи установок Ubuntu, предварительно загруженных на сертифицированные OEM-компьютеры, на которых работает эта операционная система, а также планирует ввести требование Secure Boot, требуя включения в прошивку как ключа Canonical, так и ключа Microsoft (из соображений совместимости). Fedora также использует shim, [ какой? ] , но требует, чтобы и ядро, и его модули также были подписаны. [168]
Был спор о том, должны ли быть подписаны также ядро операционной системы и его модули; в то время как спецификации UEFI не требуют этого, Microsoft заявила, что их договорные требования требуют этого, и что она оставляет за собой право отзывать любые сертификаты, используемые для подписи кода, который может быть использован для нарушения безопасности системы. [169] В Windows, если включена безопасная загрузка, все драйверы ядра должны иметь цифровую подпись; драйверы, не являющиеся WHQL, могут быть отклонены для загрузки. В феврале 2013 года другой разработчик Red Hat попытался представить исправление для ядра Linux, которое позволило бы ему анализировать подпись Authenticode Microsoft с помощью главного ключа X.509, встроенного в файлы PE , подписанные Microsoft. Однако это предложение подверглось критике со стороны создателя Linux Линуса Торвальдса , который напал на Red Hat за поддержку контроля Microsoft над инфраструктурой безопасной загрузки. [170]
26 марта 2013 года испанская группа разработчиков свободного программного обеспечения Hispalinux подала официальную жалобу в Европейскую комиссию , утверждая, что требования Microsoft к безопасной загрузке в OEM-системах являются «обструкционистскими» и антиконкурентными . [171]
На конференции Black Hat в августе 2013 года группа исследователей безопасности представила ряд эксплойтов в реализациях UEFI конкретных поставщиков, которые могут быть использованы для эксплуатации Secure Boot. [172]
В августе 2016 года сообщалось, что два исследователя безопасности обнаружили ключ безопасности «золотой ключ», который Microsoft использует для подписи операционных систем. [173] Технически, ключ не был раскрыт, однако был раскрыт эксплуатируемый двоичный код, подписанный ключом. Это позволяет любому программному обеспечению работать так, как будто оно действительно подписано Microsoft, и раскрывает возможность атак руткитов и буткитов . Это также делает исправление ошибки невозможным, поскольку любой патч может быть заменен (понижен) (подписанным) эксплуатируемым двоичным кодом. Microsoft ответила в заявлении, что уязвимость существует только в архитектуре ARM и устройствах Windows RT , и выпустила два исправления; однако исправления не устраняют (и не могут) уязвимость, что потребовало бы замены ключей в прошивке конечного пользователя для исправления. [ необходима цитата ]
1 марта 2023 года исследователи из компании ESET Cybersecurity Firm сообщили о «первом в дикой природе бутките UEFI, обходящем UEFI Secure Boot» под названием «BlackLotus» в своих публичных аналитических выводах, описывающих теорию, лежащую в основе его механики, использующей исправления, которые «не устраняют (и не могут устранить) уязвимость». [174] [175]
В августе 2024 года обновления безопасности Windows 11 и Windows 10 применили настройки Secure Boot Advanced Targeting (SBAT) к UEFI NVRAM устройства, что могло привести к сбою загрузки некоторых дистрибутивов Linux. SBAT — это протокол, поддерживаемый в новых версиях диспетчера загрузки Windows и shim, которые отказываются загружать промежуточный загрузчик с ошибками или уязвимостями (обычно winload.efi и GRUB ) в процессе загрузки. [176]
Многие дистрибутивы Linux теперь поддерживают UEFI Secure Boot, например , RHEL (RHEL 7 и более поздние версии), CentOS (CentOS 7 и более поздние версии [177] ), Ubuntu , Fedora , Debian (Debian 10 и более поздние версии [178] ), OpenSUSE , SUSE Linux . [179]
Возросшая популярность прошивки UEFI в устройствах также привела к ряду технических проблем, связанных с их реализацией. [180]
После выпуска Windows 8 в конце 2012 года было обнаружено, что некоторые модели компьютеров Lenovo с Secure Boot имели встроенное ПО, которое было жестко запрограммировано на загрузку только исполняемых файлов с именем « Windows Boot Manager » или « Red Hat Enterprise Linux », независимо от любых других настроек. [181] Другие проблемы возникли у нескольких моделей ноутбуков Toshiba с Secure Boot, у которых отсутствовали определенные сертификаты, необходимые для его правильной работы. [180]
В январе 2013 года была опубликована ошибка, связанная с реализацией UEFI на некоторых ноутбуках Samsung , из-за которой они зависали после установки дистрибутива Linux в режиме UEFI. Хотя изначально виной всему были потенциальные конфликты с модулем ядра, разработанным для доступа к системным функциям на ноутбуках Samsung (что также побудило разработчиков ядра отключить модуль на системах UEFI в качестве меры безопасности), Мэтью Гарретт обнаружил, что ошибка на самом деле была вызвана сохранением слишком большого количества переменных UEFI в памяти, и что ошибка также могла быть вызвана в Windows при определенных условиях. В заключение он определил, что проблемный модуль ядра привел к записи дампов сообщений ядра в прошивку, тем самым вызвав ошибку. [53] [182] [183]
В: Какова связь между EFI и UEFI? О: Спецификация UEFI основана на спецификации EFI 1.10, опубликованной Intel, с исправлениями и изменениями, управляемыми форумом Unified EFI. Intel по-прежнему владеет авторскими правами на спецификацию EFI 1.10, но предоставила ее на форум, чтобы форум мог ее развивать. Будущих версий спецификации EFI не будет, но клиенты, которые лицензируют ее, по-прежнему могут использовать ее в соответствии с условиями своей лицензии от Intel. Лицензия на спецификацию Unified EFI исходит от форума, а не от Intel
{{cite report}}: CS1 maint: url-status ( ссылка )система, поддерживаемая Extensible Firmware Interface, основана на файловой системе FAT. EFI определяет конкретную версию FAT, которая явно документирована и может быть протестирована. Соответствие спецификации EFI и связанным с ней справочным документам является единственным определением FAT, которое необходимо реализовать для поддержки EFI. Чтобы отличить файловую систему EFI от чистой FAT, был определен новый тип файловой системы раздела.
System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby ... Платформы должны быть UEFI Class Three (см. UEFI Industry Group, Evaluating UEFI using Commercially Available Platforms and Solutions, version 0.3, для определения) без установленного или устанавливаемого модуля поддержки совместимости. Эмуляция BIOS и устаревшая загрузка PC/AT должны быть отключены.
Microsoft определила, что поставщики не будут заинтересованы в производстве собственной 32-битной прошивки UEFI из-за текущего состояния основных 64-битных вычислений и стоимости платформы. Поэтому изначально Microsoft не поставляла поддержку для 32-битных реализаций UEFI.
