Войти
Положение EFI в программном стеке Унифицированное Extensible Firmware Interface (UEFI ) - это спецификация, определяющая программный интерфейс между операционной системой и платформой прошивка. UEFI заменяет устаревший интерфейс прошивки системы ввода / вывода (BIOS ), изначально присутствовавший во всех IBM PC-совместимых компьютерных поддержки, при этом большинстве реализаций прошивки UEFI обеспечивает для устаревших служб BIOS. UEFI может поддерживать удаленную диагностику и ремонт компьютеров, даже если операционная система не установлена.
Intel разработала оригинальные спецификации Extensible Firmware Interface (EFI ). Некоторые методы и форматы данных EFI аналогичны Microsoft Windows. В 2005 году UEFI устарел EFI 1.10 (последняя версия EFI). Объединенный форум EFI - отраслевой орган, который управляет спецификациями UEFI во всем.
Исходная мотивация для EFI появилась во время разработки первых систем Intel - HP Itanium в середине 1990-х годов. Ограничения BIOS (например, 16-битный режим процессора, адресное пространство 1 МБ и аппаратное обеспечение ПК AT ) стали слишком жесткими для больших серверные платформы, на которые нацелился Itanium. Усилия по решению этих проблем начались в 1998 году и назывались Intel Boot Initiative. Позже он был переименован в Расширяемый интерфейс прошивки (EFI).
В июле 2005 года Intel прекратила указание EFI в версии 1.10 и представила ее на Unified EFI Forum, который разработал спецификацию Unified Extensible Firmware Interface (UEFI). Исходная спецификация EFI остается собственностью Intel, которая лицензию исключительно для продуктов на основе EFI, но спецификация UEFI принадлежит форуму UEFI.
Версия 2.0 в спецификации UEFI была выпущена 31 января 2006 г. Она добавлены криптография и «безопасная загрузка». Версия 2.1 спецификации UEFI была выпущена 7 января 2007 года. В нее добавлена сетевая аутентификация и архитектура пользовательского интерфейса («Инфраструктура интерфейса пользователя» в UEFI). Последняя спецификация UEFI, версия 2.8, была утверждена в марте 2019 года.
Tiano был первой реализацией UEFI с открытым исходным кодом, выпущенной Intel в 2004 году. С тех пор Tiano был заменен EDK и EDK2, теперь поддерживается сообществом TianoCore.
В декабре 2018 года Microsoft анонсировала Project Mu, ответвление TianoCore EDK2, используемое в Microsoft Surface и Продукты Hyper-V. Проект продвигает идею Прошивка как услуга.
Интерфейс, включает EFI, включает данные, содержащую информацию о платформе, а также функции и выполнение доступного загрузчика ОС. и ОС. Микропрограммное обеспечение UEFI обеспечивает несколько технических возможностей по стандартной системе BIOS:
Начиная с версии 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-битным (x86-32, AArch32) или 64-битным (x86-64, Itanium и AArch64). Реализации 64-битного микропрограммного обеспечения UEFI длинный режим, который позволяет приложениям в среде выполнения перед загрузкой использовать 64-битную адресацию для получения прямого доступа ко всем машинам.
UEFI требует наличия загрузчика микропрограмм и операционной системы (или ядро) должны соответствовать размеру; например, реализация 64-разрядного микропрограммного обеспечения UEFI может загрузить только загрузчик или ядро 64-разрядной операционной системы (ОС). После того, как система переходит из «Boot Services» в «Runtime Services», ядро операционной системы вступает во владение. На этом этапе может быть использован режим работы процессора. С версии 3.15, ядро Linux поддерживает загрузку 64-битных ядер на 32-битных реализациях микропрограмм UEFI, работающих на x86-64 CPU, с поддержкой UEFI передачи обслуживания от загрузчика UEFI в качестве требований. Протокол передачи UEFI дедуплицирует код инициализации UEFI между ядром и загрузчиками UEFI, оставляя инициализацию процесса только загрузочной заглушкой UEFI ядра Linux.
В дополнение к стандартной схеме разделов диска ПК, использующей главную загрузочную запись (MBR), UEFI также работает со схемой разделения таблицы разделов GUID (GPT), которая является бесплатной. от многих ограничений MBR. В частности, MBR ограничивает количество и размер дисковых разделов (до четырех первичных разделов на диск и до 2 TiB (2 × 2 байта ) на диск) расслаблены. В частности, GPT допускает максимальный размер диска и раздела 8 ZiB (8 × 2 байта).
Поддержка 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. Основной заголовок и таблица основных разделов). Обычно размером 1 MiB, этот раздел Глобальный идентификатор (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.
64-разрядные версии Windows Vista SP1 и более поздние версии могут загружаться с дисков размером больше раздела 2 TB.
EFI определяет два типа служб: службы загрузки и службы времени выполнения. Службы загрузки доступны только в то время, когда микропрограмма владеет платформой (то есть есть до вызова ExitBootServices), и они включают текстовые и графические консоли на различных устройствах, а также блочные и файловые службы. Во время работы системы службы времени выполнения по-прежнему доступны; они включают такие службы, как дата, время и доступ к NVRAM.
Кроме того, протокол вывода графики (GOP) обеспечивает ограниченную поддержку служб времени выполнения; см. также раздел Графические особенности ниже. Операционная система разрешено напрямую записывать в буфер кадра, предоставляемый GOP, в режиме выполнения. Однако возможность изменения видеорежимов теряется после режима службы времени выполнения, пока не будет загружен графический драйвер ОС.
Взаимодействие между диспетчером загрузки EFI и драйверами EFI Помимо ОС, UEFI может запускать приложения UEFI, которые хранятся в виде файлов на системном разделе EFI. Их можно запустить из оболочки UEFI, менеджером загрузки встроенного ПО или других приложений UEFI. Приложения UEFI можно разрабатывать и оригинального независимо от оборудования производителей (OEM).
Тип приложения UEFI - это загрузчик ОС, например GRUB, rEFInd, Gummiboot и Диспетчер загрузки Windows ; который загружает некоторые файлы ОС в память и выполняет их. Кроме того, загрузчик ОС может предоставить пользовательский интерфейс, позволяющий выбрать приложение UEFI для запуска. Такие утилиты, как UEFI Shell, также являются приложениями UEFI.
EFI определяют протоколы как набор программных интерфейсов, используемых для связи между двумя двоичными модулями. Все драйверы EFI должны услуги через протоколы.
В дополнение к стандартным драйверам устройств, зависящих от архитектуры процессора, EFI использует независимый от процессора драйвер устройства, хранящийся в энергонезависимой памяти как байт-код EFI или EBC. В системной прошивке есть интерпретатор образовательный EBC. В этом смысле EBC аналогичен Open Firmware, аппаратно-независимой прошивке, используемой в PowerPC -based Apple Macintosh и Sun Microsystems SPARC компьютеры, среди прочего.
Некоторые зависящие от архитектуры (не относящиеся к байтовому коду EFI) драйверы EFI для некоторых устройств могут использовать интерфейс для использования ОС. Это позволяет ОС EFI для основных графических и сетевых функций и программ для конкретной операционной системы.
Другие драйверы EFI могут быть драйверы файловой системы, позволяющие загружать с дисковых томов других типов. Примеры включают файлы efif для 37 файловых систем (на основе кода GRUB2 ), используя Rufus для последовательной загрузки файловых систем NTFS.
Спецификация EFI определяет протокол UGA (универсальный графический адаптер) как способ поддержки устройства графики. UEFI не включал UGA и заменял его GOP (протоколом вывода графики) с явной целью удаления аппаратных зависимостей VGA. Они похожи.
UEFI 2.1 определил «Инфраструктуру интерфейса пользователя» (HII) для управления вводом пользователем, локализованными строками, шрифтами и формой (в смысле HTML ). Это позволяет производителя оригинального оборудования (OEM) или независимым поставщикам BIOS (IBV) разрабатывать графические интерфейсы для конфигурации перед загрузкой.
Самые ранние реализации встроенного ПО UEFI были консольными. Сегодня многие прошивки UEFI основаны на графическом интерфейсе.
Системный раздел EFI, часто сокращенно ESP, представляет собой раздел устройства хранения данных, который используется в компьютере в заявлении UEFI. Прошивка UEFI, доступ к которой осуществляется при включении компьютера, хранятся приложения UEFI и файлы, которые могут запускаться, включая загрузчики операционной системы . Поддерживаемые схемы таблицы разделов включают MBR и GPT, а также тома El Torito на оптических дисках. Для использования в ESP UEFI определяет конкретную версию файловой системы FAT, которая существует как часть спецификации UEFI независимо от исходной спецификации FAT, включая вариант FAT32 файловая система на ESP и файловые системы FAT16 и FAT12 на съемном носителе. ESP также предоставляет место для загрузочного сектора в обратной совместимости с BIOS.
В устаревшей BIOS ПК, UEFI не полагается на загрузочные секторы, вместо опися диспетчера загрузки как часть этой спецификации UEFI. Когда включен диспетчер загрузки проверяет загрузку конфигурации и на ее настройках, загружается в память, а затем исполняется загрузчик ОС или ядро операционной системы. Конфигурация включает переменными, хранящимися в NVRAM, включая переменные, указывающие пути файловой системы к загрузчикам ОС или ядрам ОС.
Загрузчики ОС могут быть автоматически обнаружены UEFI, что позволяет легко загрузить со съемных устройств, таких как USB-накопители. Это автоматическое обнаружение основывается на стандартизованных путях файлов загрузчика ОС, причем путь зависит от архитектуры компьютера . Формат пути к файлу определяется как
Загрузка систем UEFI с дисков с разделами GPT обычно называется загрузкой UEFI-GPT. Несмотря на то, что спецификация UEFI требует полной поддержки таблиц разделов MBR, некоторые реализации микропрограмм UEFI немедленно переключаются на загрузку CSM на основе BIOS в зависимости от типа таблицы разделовочного диска, эффективно предотвращает выполнение UEFI из Системный раздел EFI на загрузку. дисках с разделами MBR. Такая схема использования обычно называется UEFI-MBR.
Диспетчер загрузки также имеет текстовый пользовательский интерфейс, поэтому пользователь может выбрать желаемую ОС (или системную утилиту) из доступных параметров.
Для поддержки обратной совместимости микропрограмм 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 году.
Спецификация UEFI включает поддержку загрузки в сети через Preboot eXecution Environment (PXE). При загрузке PXE используются сетевые протоколы, включая Интернет-протокол (IPv4 и IPv6 ), протокол дейтаграмм пользователя (UDP), Протокол динамической конфигурации хоста (DHCP), Простой протокол передачи файлов (TFTP) и iSCSI.
Образы ОС могут удаленно храниться в сетях хранения данных (SAN), с Интерфейс малых вычислительных систем Интернета (iSCSI) и Fibre Channel over Ethernet (FCoE) в качестве поддерживаемых протоколов для доступа к SAN.
Версия 2.5 спецификация верхнего уровня UEFI поддержки доступа к официальному загрузочному образцу по протоколу HTTP.
Спецификация UEFI 2.3.1 Errata C ( Защищает процесс загрузки, предотвращает загрузку драйверов ОС, которые не подписаны с приемлемой подписью. Механические детали того, как эти драйверы должны быть подписаны, не указаны. Когда безопасная загрузка включена, она изначально переводится в режим «настройки», который позволяет записывать в микропрограмму открытый ключ, известный как «ключ платформы» (PK). После ключа безопасная загрузка переходит в режим «Пользователь», в котором загружены драйверы и загрузчики, подписанные ключом платформы. Дополнительные "" (KEK) могут быть добавлены в базу данных, хранящуюся в памяти, чтобы разрешить использование других сертификатов, но они должны иметь соединение с закрытой платформой ключа платформы. Безопасная загрузка также может быть переведена в «Пользовательский» режим, в котором в систему могут быть добавлены дополнительные открытые ключи, не соответствующие закрытому ключу.
Безопасная загрузка поддерживается Windows 8 и 8.1, Windows Server 2012 и 2012 R2, а также Windows 10, VMware vSphere 6.5 и ряд дистрибутивов Linux, включая Fedora (с версии 18), openSUSE (с версии 12.3), RHEL (с версии 7), CentOS ( с версии 7), Debian (с версии 10) и Ubuntu (с версии 12.04.2). По состоянию на январь 2017 года поддержка FreeBSD находится на стадии планирования.
UEFI предоставляет среду оболочки, которую можно использовать для выполнения других приложений UEFI, включая загрузчики UEFI . Кроме того, команда, доступная в оболочке UEFI, передача информации о системе или прошивке, включая получение карты памяти (memmap), изменение числа диспетчера загрузки (bcfg), запуск программ разметки (diskpart ), загрузка драйверов UEFI и редактирование текстовых файлов (редактировать).
Исходный код для оболочки UEFI можно загрузить с Проект Intel TianoCore UDK / EDK2. Также приветствующий собранный ShellBinPkg. Shell v2 лучше всего работает в системах с UEFI 2.3+ и рекомендуется оболочки v1 в этих системах. Оболочка v1 должна работать во всех системах UEFI.
Методы, используемые для запуска оболочки UEFI, зависят от производителя и модели системы материнская плата. Некоторые из них уже прямую возможность в настройке прошивки для запуска, например, скомпилированная версия оболочки x86-64 должна быть доступна как
Ниже приведен список команд, поддерживаемых оболочкой EFI.
Расширения для UEFI могут быть загружены практически из любого энергонезависимого запоминающее устройство, подключенное к компьютеру. Например, производитель оригинального оборудования (OEM) может распространять систему с системным разделом EFI на жестком диске, что дополнительные функции к стандартной прошивке UEFI, хранящейся на материнской плате ROM.
Капсула UEFI определяет современный и безопасный интерфейс обновления микропрограмм между микропрограммами. Windows 8, Windows 8.1, Windows 10 и Fwupd для Linux панель UEFI Capsule.
Машины UEFI могут иметь один из «следующих», которые использовались для облегчения классов на UEFI. Intel завершила UEFI CSM в 2020 году.
Это первый этап загрузки UEFI, но может иметь предшествующий ему двоичный код платформы. (например, Intel ME, AMD PSP ). Минимальный код написан на ассемблере для конкретной архитектуры. Он инициализирует временную память (часто кэш ЦП в ОЗУ) и служит программным корнем доверия системы проверки PEI перед передачей.
Второй этап загрузки UEFI включает из диспетчера зависимостей, который загружает и запускает модули PEI (PEIM) для обработки задач начальной инициализации оборудования, как основная память инициализация и восстановление. Кроме того, он обеспечивает выполнение многих операций по загрузке и обработке ACPI S0ix / S3. В случае возобновления ACPI S0ix / S3 он отвечает за восстановление многих аппаратных регистров до состояния, предшествующего спящему режиму. PEI также использует кэш ЦП в качестве ОЗУ.
Этот этап также состоит из модулей C и диспетчера с учетом зависимостей. Теперь, когда используется основная память, инициализирует основные драйверы оборудования, код функций, шину PCI и службы времени (UEFI ->ОС).
На этом этапе обычно инициализируются устройства ввода и вывода, выполняются драйверы или дополнительные ПЗУ на устройствах PCI в соответствии с конфигурацией системы, варианты загрузки на предмет наличия, заказа и оборудования устройств.
Это этап между выбором загрузки и передачей ОС. На этом этапе можно войти в программу установки, оболочку UEFI или запустить приложение EFI, такое как загрузчик ОС.
UEFI переключается на ОС. ОС, совместимая с UEFI, теперь отвечает за выход из служб, запускающий микропрограмму для выгрузки всего ненужного кода и данных, оставляя только режим управления системой (SMM) и код / данные службы времени выполнения.
Когда используется устаревшая ОС, CSM будет обрабатывать вызов, совместимость с устаревшей устаревшей BIOS.
Реализация Intel EFI - это платформа Intel Platform Innovation Framework под кодовым названием Tiano. Tiano работает на процессорах Intel XScale, Itanium и IA-32 и является проприетарным программным продуктом, хотя часть выпущена под лицензией Лицензия BSD или Общественная лицензия Eclipse (EPL) как TianoCore . TianoCore можно использовать в качестве полезной нагрузки для coreboot.
Phoenix Technologies. Реализация UEFI под торговой маркой SecureCore Technology (SCT). American Megatrends предлагает использовать собственные прошивки UEFI, известную как Aptio, в то время как Insyde Software предлагает InsydeH2O, собственные собственные Tiano.
В декабре 2018 года Microsoft выпустила версию с открытым исходным кодом своей реализации UEFI на основе TianoCore EDK2 от строки Surface, Project Mu.
Реализация UEFI API представлена в универсальном загрузчике (Das U-Boot ) в 2017 году. На архитектуре ARMv8 Linux дистрибутивы использовать использование UEFI U-Boot в сочетании с 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 вместо Open Firmware, которое использовалось в его предыдущих системах на базе PowerPC. 5 апреля 2006 года Apple впервые выпустила Boot Camp, который создает диск с драйверами Windows и инструмент неразрушающего разбиения, позволяющий установить Windows XP или Vista без необходимости переустановки Mac OS X. Прошивка Также было выпущено обновление, совместимость с BIOS в его как EFI. Последующие модели Macintosh поставлены с более новой прошивкой.
В течение 2005 года более миллиона систем поставляются Intel с внедрением Intel UEFI. Новые мобильные, настольные и серверные продукты, которые используются для реализации Intel UEFI, начали поставляться в 2006 году. Например, используются платы, используя серию наборов микросхем Intel 945, используйте использование встроенного ПО Intel UEFI.
С 2005 года EFI также внедряется на автомобилях, отличных от ПК, таких как встроенные системы на основе XScale баллов.
EDK (EFI Developer Kit) включает цель NT32, которая позволяет микропрограммному обеспечению EFI и приложениям EFI работать в приложении Windows. Но EDK NT32 не разрешает прямой доступ к оборудованию. Это означает, что на целевом объекте EDK NT32 может быть только часть приложений EFI и драйверов.
В 2008 году большее количество систем x86-64 приняли UEFI, некоторые из них использовали меню rEFInd GUI. Хотя многие из этих систем по-прежнему позволяют загружать только ОС BIOS через модуль поддержки совместимости (CSM) (таким образом, не представляясь пользователям как основанные на UEFI), другие системы начали разрешать загрузку ОС на основе UEFI. Например, сервер IBM x3450, материнские платы MSI с ClickBIOS, все ноутбуки и планшеты HP EliteBook, более новые ноутбуки HP Compaq (например, 6730b, 6735b и т. Д.).
В 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-series LGA 1155 и чипсеты AMD 9 Series AM3 + с UEFI.
С выпуском Windows 8 в октябре 2012 года сертификационные требования Microsoft теперь требуют, чтобы компьютеры включали микропрограммное обеспечение, реализующее спецификацию UEFI. Кроме того, если компьютер поддерживает функцию «Connected Standby » в Windows 8 (которое позволяет устройствам управлять питанием, сопоставимым с смартфонами, с почти мгновенным выходом из режима ожидания), тогда микропмное обеспечение не может содержать модуль поддержки совместимости (CSM). Таким образом, системы, поддерживающие Connected Standby, не могут загружать операционные системы Legacy BIOS.
В октябре 2017 года Intel объявила, что к 2020 году она откажется от поддержки устаревших BIOS для ПК во всех своих продуктах в пользу UEFI Class 3..
Операционная система, которая может быть загружена из (U) EFI, называется (U) EFI-совместимой операционной системой в соответствии со спецификацией (U) EFI. Здесь термин «загрузка из (U) EFI» означает прямую загрузку системы с использованием загрузчика операционной системы (U) EFI, хранящегося на любом устройстве хранения. Местоположение загрузчика операционной системы по умолчанию: IA32, X64, IA64, ARMили AA64. Некоторые поставщики операционных систем могут иметь свои собственные загрузчики. Они также могут изменить место загрузки по умолчанию.
Комплект разработки приложений EDK2 (EADK) позволяет использовать стандартные функции библиотеки C в приложениях UEFI. EADK можно бесплатно загрузить из проекта Intel TianoCore UDK / EDK2 SourceForge. Например, порт интерпретатора Python становится доступным как приложение UEFI с помощью EADK. С момента выхода UDK2015 разработка переместилась на GitHub.
Минималистичная программа на C "hello, world ", написанная с использованием EADK, похожа на ее обычный аналог на C :
#include#include #include EFI_STATUS EFIAPI ShellAppMain (IN UINTN Argc, IN CHAR16 ** Argv) {Print (L "привет, мир \ n"); вернуть EFI_SUCCESS; }
Многие активисты цифровых прав протестовали против UEFI., соавтор coreboot, и Кори Доктороу, активист цифровых прав, раскритиковали EFI как попытку лишить пользователя возможности по-настоящему управлять компьютером. Это не решает давних проблем BIOS, связанных с необходимостью двух разных драйверов - для одного микропрограммного обеспечения и одного для системы - для международного оборудования.
Проект с открытым исходным кодом TianoCore также предоставляет интерфейсы UEFI. TianoCore не хватает драйверов, которые инициализируют функции набора микросхем, вместо этого пособия coreboot, из которых TianoCore является одним из многих вариантов полезной нагрузки. Разработка coreboot требует сотрудничества со стороны производителей наборов микросхем для предоставления спецификаций, необходимых для разработки драйверов инициализации.
В 2011 году Microsoft объявила, что компьютеры, сертифицированные для работы с ее операционной системой Windows 8, должны поставляться с зарегистрированным открытым ключом Microsoft и включенной безопасной загрузкой. После объявления критики и сторонники программного обеспечения открытого исходного кода (в том числе Free Software Foundation ) обвинили компанию в попытке использовать безопасную загрузку UEFI для затруднения или полного предотвращения установка альтернативных операционных систем, таких как Linux. Microsoft отрицала, должна разрешить безопасную загрузку для перехода в пользовательский режим или отключено, но разъяснила его требования, указав, что система на базе x86, сертифицированные для Windows 8, должны разрешить безопасную загрузку для перехода в пользовательский режим или отключено, но не в системе с архитектурой АРМ. Windows 10 позволяет OEM-производителю решать, могут ли пользователи их систем x86 управлять безопасной загрузкой.
Другие разработчики выразили озабоченность по поводу юридических и практических вопросов реализации поддержки безопасной загрузки систем Linux в целом. Бывший разработчик Red Hat Мэтью Гаррет отметил, что условия в Стандартной общественной лицензии GNU версии 3 могут препятствовать использованию загрузчика GNU Grand Unified без раскрытия разработчиком дистрибутива закрытого ключа (однако Фонд свободного программного обеспечения с тех пор разъяснил свою позицию, заверил, что ответственность за предоставление ключей лежит на производителе оборудования), и что он также будет Для опытных пользователей сложно создать собственные ядра, которые могли бы работать с безопасной загрузкой без их самоподписи. Другие разработчики предложили предоставить подписанные сборки Linux с ключом, но отметили, что будет трудно предложить производителям OEM-производителей свои компьютеры с требуемым ключом вместе с ключом Microsoft.
Было разработано несколько основных дистрибутивов Linux. различные реализации для безопасной загрузки. Сам Гарретт разработал минимальный загрузчик, известный как оболочка оболочки, которая представляет собой оболочку оболочки, которая позволяет индивидуально доверять ключам, предоставленным дистрибьюторами. Ubuntu 12.10 использует старую версию оболочки, настроенную для использования с Собственный ключ Canonical, который проверяет только загрузчик и загружает неподписанные ядра; Разработчики считали, что практика подписания только загрузчика более осуществима, поскольку доверенное ядро защищает только пользовательское пространство, а не состояние перед загрузкой, которое безопасная загрузка для дополнительной защиты. Это также позволяет создавать свои собственные ядра и использовать собственные модули ядра без необходимости перенастраивать систему. Canonical также поддерживает свой собственный закрытый ключ для подписи установок Ubuntu, загруженных на сертифицированных OEM-компьютерах, на которых установлена операционная система, а также обеспечивает соблюдение безопасной загрузки, требующих наличия ключей Canonical, так и ключа Microsoft (по соображениям совместимости) для включения в их прошивку. Fedora также использует оболочку оболочки, но требует, чтобы и ядро, и его модули также были подписаны.
Спорный вопрос о том, может также подписываться ядро и его модули; Хотя в спецификации UEFI этого не требуют, Microsoft заявила, что их договорные требования соответствуют требованиям, и что она оставляет за собой право отозвать любые сертификаты, используемые для подписи кода, который может быть использован для нарушения безопасности системы. В феврале 2013 года другой разработчик Red Hat попытался отправить патч для ядра Linux, который позволил бы ему проанализировать подпись аутентификационного кода Microsoft с использованием главного ключа X.509, встроенного в подписанные файлы PE. от Microsoft. Однако это предложение подверглось критике со стороны разработчика Linux Линуса Торвальдса, который атаковал Red Hat за поддержку контроля Microsoft над инфраструктурой безопасной загрузки.
26 марта 2013 г. испанский группа разработки свободного программного обеспечения Hispalinux подала официальную жалобу в Европейскую Комиссию, утверждая, что требования Microsoft к безопасной загрузке OEM-систем были «препятствующими» и антиконкурентными.
Black На конференции Hat в августе 2013 года группа исследователей безопасности представила серию эксплойтов в реализациих UEFI специальных поставщиков, которые могут использовать для использования безопасной загрузки.
В августе 2016 года сообщалось, что два исследователя безопасности нашла ключ безопасности «золотой ключ», который Microsoft использует для подписи в операционных системах. Технически ключ не был раскрыт, однако был открыт бинарный файл, подписанный ключ. Это позволяет любому программному обеспечению работать так, как если бы оно было подлинно подписано Microsoft, и делает возможными атаки руткитов и буткитов. Это также делает невозможным исправление ошибки, поскольку любой патч может быть заменен (понижен до версии) на (подписанный) используемый бинарный файл. Microsoft ответила заявлением, что уязвимость существует только в устройствах с архитектурой ARM и Windows RT, и выпустила два исправления; однако патчи не устраняют (и не могут) устранить уязвимость, для исправления которой потребовалась бы замена ключей в прошивке конечного пользователя.
Многие дистрибутивы Linux теперь входят безопасную загрузку UEFI, например RHEL (RHEL 7 и новее), Cent OS (CentOS 7 и новее), Ubuntu, Debian (Debian 10 и новее), OpenSUSE, SUSE Linux.
Возросшее значение прошивки UEFI в устройствах также привело к ряду технических проблем, связанных с их поставками.
После Windows 8 в конце 2012 года было обнаружено, что некоторые модели компьютеров Lenovo с безопасной загрузкой имели прошивку, которая жестко запрограммирована так, чтобы разрешать только исполняемые файлы с именем «Windows Boot Manager "или" Red Hat Enterprise Linux "для пользователей независимо от других систем. Проблемы столкнулись с моделями ноутбуков Toshiba с безопасной загрузкой, в которых отсутствовали
В январе 2013 года обнаружена ошибка, связанная с реализацией UEFI на некоторых Были опубликованы ноутбуки Samsung, из-за чего они были заблокированы после установки дистрибутива Linux в режиме UEFI. Хотя изначально обвиняли в конфликтах с модулем ядра, предназначенном для доступа к системным функциям на ноутбуках Samsung. в системе UEFI в качестве меры безопасности), Мэтью Гарретт обнаружил, что ошибка на самом деле вызвана огромным количеством UEFI. переменные в память, и что ошибка также может быть вызвана под Windows при определенных условиях. В заключении он определил, что неисправный модуль ядра привел к записи дампов сообщений ядра в прошивку, что вызвало ошибку.
 | Викискладе есть материалы, связанные с Extensible Firmware Interface. |
