EFI (Extensible Firmware Interface)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:27, 25 октября 2018.
(перенаправлено с «Extensible Firmware Interface»)
EFI (Extensible Firmware Interface)
1480857540 13 02-368px-uefi-logo-svg.png
Создатели: Intel и HP
Разработчики: Intel и HP
Выпущена: середина 90-х годов 20 века
Постоянный выпуск: 2.6 / январь 2016 года
Состояние разработки: Активное
Тип ПО: интерфейс по централизации оборудования в момент включения системы
Веб-сайт www.intel.ru/content/www/ru/ru/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html
Extensible Firmware Interface, позже United EFI - интерфейс по централизации оборудования в момент включения системы. Регулирует процессы, происходящие между операционной системой и микропрограммами, осуществляющими управление низкоуровневыми функциями оборудования. EFI загружает компьютер, а впоследствии передает управление загрузчику операционной системы. Является логической заменой интерфейса BIOS, традиционно исользующегося IBM PC-совместимыми компьютерами[1].

Для большего понимания, UEFI по сравнению с BIOS - это, грубо говоря, новый тип или следующее поколение прошивки, и оно уже не ограничено только лишь персональными компьютерами архитектуры x86-64 (IBM PC), но и претендует на всеплатформенный стандарт. Однако, в отличии от BIOS, UEFI базируется на принципиально новой топологии кода, которая называется "драйверность".

Основное назначение EFI - замена устаревающей технологии BIOS и связанных с ней ограничений.

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

Основная задача EFI - корректно инициализировать оборудование и передать управление загрузчику операционной системы. В этом плане задача не сильно то и отличается от задачи традиционного BIOS, но алгоритмы принципиально другие.

История

Первоначально, стандарт EFI предназначался для использования в первых системах Intel-HP Itanium, появившихся в середине 90-х годов. Те ограниченные возможности, которые демонстрировал PC-BIOS (16-битный код, адресуемая память 1 Мбайт, ограничения аппаратного характера IBM PC/AT и прочее) были неприемлемы для использования в больших серверных платформах, а ведь Itanium планировался именно для таковых.

Примечательно, что EFI изначально носил название Intel Boot Initiative, это уже позже он был переименован.

  • спецификация EFI 1.02 была выпущена Intel 12 декабря 2000 года (версия 1.01 имела юридические проблемы, связанные с торговой маркой, и была быстро изъята);
  • спецификация EFI 1.10 была выпущена 1 декабря 2002 года. Она включала модель драйвера EFI, а также несколько незначительных улучшений по сравнению с версией 1.02;
  • в 2005 году Intel внесла эту спецификацию в UEFI Forum, который теперь ответственен за развитие и продвижение EFI. EFI был переименован в Unified EFI (UEFI), чтобы отразить это изменение, при этом большая часть документации использует оба термина;
  • UEFI Forum выпустил спецификацию 2.1 UEFI 7 января 2007 года. Она добавила и улучшила криптографию, установление подлинности сети и архитектуру пользовательского интерфейса;
  • версия 2.3.1 была принята в апреле 2011 года;
  • версия 2.4 была принята в июле 2013 года;
  • версия 2.5 была принята в апреле 2015 года.
  • версия 2.6 была принята в январе 2016 года.

Алгоритм работы UEFI

В процессе разработки UEFI, разработчика, с самого начала, были установлены жесткие рамки для каждого процесса, участвующего в ходе выполнения. Первые три фазы (SEC, PEI, DXE) подготавливают платформу для загрузчика ОС, четвертая фаза (BDS) непосредственно производит загрузку загрузчика ОС. Давайте попробуем разобрать алгоритм работы UEFI и подробнее рассмотреть все его фазы[2].

Фаза SEC

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

  • Запуск главной процедуры инициализации в ROM.
  • Переход в защищенный режим работы процессора.
  • Инициализируются MTRR (диапазонные регистры типа памяти) для BSP.
  • Запуск патчей микрокода для всех установленных процессоров.
  • Начальная работа с BSP/AP. BSP = Board Support Package. AP = Application Processor. Каждое ядро может быть представлено как BSP + AP. Всем AP рассылается IIPI (Init Inter-processor Interrupt), затем SIPI (Start-up Inter-processor Interrupt).
  • Передача данных и управления в фазу PEI.

Фаза PEI

Подготовка платформы (памяти и обнаруженных устройств) для главной процедуры инициализации системы в фазе DXE.

  • Перенос данных из ROM в кеш.
  • Инициализация CRTM (Core Root for Trust of Measurement). Это набор инструкций, который запускается платформой в ходе выполнения RTM-операций.
  • Загружается диспетчер PEI. Диспетчер загружает серию модулей (PEIM), которые варьируются в зависимости от платформы. Эти модули завершают оставшиеся задачи PEI. Стадия завершается, когда все модули загружены.
  • PEIM: Загружаются и запускаются модули инициализации процессоров. (пример: модуль кеша процессора, модуль выбора частоты процессора). Инициализируются процессоры.
  • PEIM: Встроенные интерфейсы платформы инициализируются (SMBus). Инициализируются MCH (Memory Controller Hub), ICH (I/O Controller Hub).
  • PEIM: инициализация памяти. Инициализация основной памяти и перенос в нее данных из кэша.
  • Проверка режима S3. Нет - передача управления в фазу DXE. Да - восстановление исходного состояния процессора и всех устройств и переход к ОС.

Фаза DXE

Загрузка компонентов этой фазы базируется на ресурсах, которые были инициализированы в фазе PEI. Фаза окончательной инициализации всех устройств. Активация служб UEFI: Boot Services, Runtime Services и DXE Services.

  • Загружается ядро DXE. Создается инфраструктура DXE: создаются необходимые структуры данных, база данных хендлов. Включает основные интерфейсы DXE.
  • Запускает ряд сервисов: сервисы этапа загрузки (Boot Services), сервисы этапа выпонения (Runtime Services), сервисы фазы DXE (DXE Services).
  • Запуск диспетчера DXE. Посредством переданного из PEI списка Hand-off Block структур (HOB list) определяет доступные Firmware Volume (FV, структурированная база данных исполняемых модулей DXE: драйверов и приложений) и ищет в них драйвера, запускает их, соблюдая зависимости. В этот момент производится активация остальных компонентов, причем одновременно нескольких. Диспетчер грузит все доступные драйвера со всех доступных носителей.
  • Загрузка драйвера SMM Init. Инициирует подфазу. SMM (System management mode) - один из привилегированных режимов исполнения кода x86-процессора, в котором процессор переключается на независимое адресное пространство, сохраняет контекст текущей задачи, затем выполняет необходимый код, затем возвращается в основной режим. Зачем нам SMM? А потому что в этом режиме можно сделать с системой все что угодно и не зависимо от ОС. Код SMM может исполняться и после окончания фазы DXE.

Фаза BDS

Реализует политику загрузки платформы. Основная задача - подключить устройства, необходимые для загрузки, выбрать (вручную или автоматически) устройство загрузки и загрузиться с него. Зачастую выполняет рекурсивный поиск по всем доступным FV и пытается найти доступный для загрузки контент.

  • Инициализируются консольные устройства, описываемые переменными окружения ConOut (ConsoleOutHandle), ConIn (ConsoleInHandle), StdErr (StandardErrorHandle).
  • Загружаются UEFI-драйвера устройств, перечисленные в переменной окружения DriverOrder (содержащей опций Driver#### в порядке загрузки).
  • Загружается UEFI-приложение с устройства загрузки Boot####. Списки устройств содержатся в переменной окружения BootOrder в порядке очередности загрузки.
  • Если не смогли выполнить что-либо из вышеперечисленного, то вызываем диспетчер DXE для проверки обеспечения зависимостей дополнительных драйверов с момента последнего вызова диспетчера. После чего управление опять возвращается в фазу BDS.

Реализация системы EFI

Платформы

Itanium

Выпущенные в 2000 году Intel системы на платформе Itanium поддерживали EFI 1.02. Выпущенные в 2002 году Hewlett-Packard системы на платформе Itanium 2 поддерживали EFI 1.10; они могли загружать Windows, Linux, FreeBSD и HP-UX. Все системы Itanium или Itanium 2, которые выпускаются с EFI-совместимым встраиваемым ПО, должны соответствовать спецификации DIG64.

Большое количество системных плат фирмы Intel выпускается с встраиваемым ПО на основе инструментария. Так, в течение 2005 года было выпущено более одного миллиона систем Intel. Новые мобильные телефоны, настольные компьютеры и серверы, использующие инструментарий, начали производить в 2006 году. Например, все системные платы, которые построены на наборе системной логики Intel 945, используют инструментарий. Однако, производимое встраиваемое ПО обычно не включает поддержку EFI и ограничено поддержкой BIOS.

Gateway

В ноябре 2003 года, Gateway представила Gateway 610 Media Center — первую x86 компьютерную систему на основе Windows, использующую встраиваемое ПО, основанное на инструментарии, InsydeH2O от Insyde Software. Поддержка BIOS была реализована с помощью модуля поддержки совместимости (CSM) для загрузки Windows.

Apple Macintosh

В январе 2006 года Apple Inc. представила первые компьютеры Apple Macintosh на платформе Intel. Эти системы используют EFI и инструментарий вместо Open Firmware, который использовался на предыдущих системах платформы PowerPC.

5 апреля 2006 года Apple выпустила пакет Boot Camp, который позволяет создать диск с драйверами Windows XP, а также содержит неразрушающий инструмент разметки дисков, позволяющий установить Windows XP совместно с Mac OS X. Также было выпущено обновление встраиваемого ПО, которое добавило поддержку BIOS для данной реализации EFI. Последующие модели Apple Macintosh были выпущены с обновлённым встраиваемым ПО. Теперь все современные компьютеры Apple Macintosh могут загружать BIOS-совместимые ОС, такие как Windows XP, Microsoft Windows Vista и Microsoft Windows 7.

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

Linux

Linux могли использовать EFI при загрузке с начала 2000 года, используя загрузчик EFI elilo или появившиеся позднее EFI-версии загрузчика grub

HP-UX

HP-UX начали использовать EFI как загрузочный механизм в системах на платформе IA-64 с 2002 года. ОС OpenVMS использовала его начиная с января 2005 года.

Apple

Apple приняла EFI для линейки своих компьютеров, основанных на архитектуре Intel (Intel-based Macs). Mac OS X 10.4 (Tiger) для Intel и Mac OS X 10.5 (Leopard) поддерживают EFI v1.10 в 32-разрядном режиме, а также на 64-разрядных центральных процессорах (новые Macintosh имеют 64-разрядный EFI)

Itanium версии Microsoft Windows 2000 (Advanced Server Limited Edition и Datacenter Server Limited Edition) получили поддержку EFI 1.1 в 2002 году.

Windows

Microsoft Windows Server 2003 для IA-64, 64-разрядная версия Windows XP и Microsoft Windows 2000 Advanced Server Limited Edition, предназначенные для семейства процессоров Intel Itanium, поддерживают EFI, определённый для данной платформы спецификацией DIG64.

Microsoft ввела поддержку UEFI в 64-разрядных ОС Windows начиная с Windows Server 2008 и Windows Vista Service Pack 1. Microsoft утверждает, что отсутствие официальной поддержки EFI на 32-разрядных ЦП происходит из-за недостаточной поддержки изготовителями ПК и поставщиками. Миграция Microsoft к 64-разрядным ОС не позволяет использовать EFI 1.10, так как 64-разрядные расширения процессора, необходимые этим ОС, не поддерживаются окружением процессора. Поддержка x86-64 была включена в UEFI 2.0.

Microsoft выпустила видео с Эндрю Рицом (англ. Andrew Ritz) и Джейми Шварцем (англ. Jamie Schwarz), разъясняющим реализацию поддержки UEFI в Windows Vista и Microsoft Windows Server 2008.

Драйвера

В дополнение к стандартным, архитектурно-зависимым драйверам устройств, спецификация EFI предусматривает независимую от платформы среду драйверов, названную EFI Byte Code (EBC). От системного встраиваемого ПО (firmware) спецификацией UEFI требуется иметь интерпретатор для любых образов EBC, которые загружены или могут быть загружены в среду. В этом смысле, EBC подобен Open Firmware, независимому от аппаратных средств встраиваемому ПО, используемому в компьютерах Apple Macintosh и Sun Microsystems SPARC.

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

Оболочка

Сообщество EFI создало открытую среду оболочки (shell environment). Пользователь для выполнения некоторых операций может загрузить оболочку EFI (EFI shell), вместо того, чтобы загружать ОС. Оболочка – приложение EFI; она может постоянно находиться в ПЗУ платформы или на устройстве, драйверы для которого находятся в ПЗУ.

Оболочка может использоваться для выполнения других приложений EFI, таких как настройка, установка ОС, диагностика, утилиты конфигурации и обновления прошивок. Она также может использоваться, чтобы проиграть CD или DVD носители, не загружая ОС, при условии, что приложения EFI поддерживают эти возможности. Команды оболочки EFI также позволяют копировать или перемещать файлы и каталоги в поддерживаемых файловых системах, загружать и выгружать драйверы. Также оболочкой может использоваться полный стек TCP/IP.

Названия команд оболочки часто наследуются от интерпретаторов командной строки (COMMAND.COM или UNIX shell). Оболочка EFI может рассматриваться как функциональная замена интерпретатора командной строки и текстового интерфейса BIOS.

Преимущества и недостатки

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

  • Поддержка носителей информации (дисков) большого объема. Поддержкой больших дисков EFI обязан новому стандарту таблиц разделов под названием GPT (GUID Partition Table). Традиционный способ загрузки в BIOS использовал загрузочный сектор Master Boot Record (MBR), содержащий в себе таблицу разделов, которая описывала размещение разделов (партиций) диска. У таблицы разделов в MBR имеется один существенный недостаток, размерность записи о разделе в ней была всего-лишь 32 бита, соответственно, адресоваться возможно только 4 миллиарда секторов по 512 байт каждый (а это приблизительно ~2.2 Тб дискового пространства). EFI же, при помощи GPT, дает возможность адресовать диски объемом до 18 экзабайт.
  • Прямая поддержка файловых систем и таблиц разделов. UEFI имеет модули поддержки файловых систем и таблиц разделов, то есть умеет работать как с таблицами разделов, так и с файловыми системами напрямую. Спецификация подразумевает обеспечение поддержки таблицы разделов GPT, файловых системам FAT12, FAT16, FAT32 на жестких дисках и файловой системы ISO 9660 на CD/DVD дисках. Это избавляет нас от необходимости писать код начальной загрузки (по аналогии с MBR), который будет по цепочке грузить загрузчики различных стадий.
  • Отсутствие других традиционных ограничений MBR. Например больше не требуется втискивать код начальной загрузки в миниатюрный сектор размером в 512 байт. Теперь можно сосредоточиться на написании единого модуля загрузки, который будет совмещать в себе все необходимые стадии.
  • Независимые от платформы драйвера оборудования. EFI имеет доступ к аппаратному обеспечению компьютера посредством платформо-независимых драйверов. Производителю устройства достаточно написать всего-лишь одну версию драйвера для всех платформ (x86, ARM, Itanium, Alpha), а это значительно упрощает разработку и ускоряет процесс выявления ошибок. Спецификация EFI описывает взаимодействие драйверов EFI с операционной системой, таким образом, в случае, когда в ОС отсутствует драйвер, к примеру, видеокарты, а в EFI он присутствует, загружен и функционирует, то ОС имеет возможность выводить данные на монитор посредством стандартных интерфейсов EFI.
  • Поддержка стека протоколов TCP: IPv4/IPv6. Позволяет использовать богатые сетевые возможности непосредственно из интерфейса UEFI. Теперь можно разрабатывать различные загрузки по http/ftp протоколам, тут же на ум приходит загрузка с указанием URL, по которому лежит обычный EFI-модуль, либо полноценный ISO-образ. Стало возможным обойти уже успевшую стать единственно-возможным вариантом, загрузку по сети с использованием PXE/TFTP. Некоторые, особенно продвинутые реализации, могут реализовать поддержку PXE через IPv6.
  • Поддержка традиционной модели BIOS. EFI не нужен классический BIOS, однако многие производители встраивают код эмуляции BIOS, в целях поддержки работоспособности старых операционных систем. Называется этот модуль - модулем поддержки совместимости Compatibility Support Module (CSM). CSM включает 16-битный модуль (CSM16), реализуемый изготовителем BIOS, и слой, связывающий CSM16 с инструментарием (интерфейсом и оборудованием). Совместимость подразумевает поддержку загрузки посредством MBR и поддержку на уровне кода программных прерываний (int 10h - видеосервис, int 13h - сервис работы с диском, int 15h - сервисные функции, int 16h - сервис клавиатуры, int 18h - ROM-BASIC сервис, int 19h - сервис начальной загрузки (bootstrap loader)). Поэтому те ОС и ПО, которым для работы как воздух необходим был старый-добрый BIOS, спокойно могут работать и на машинах с EFI.
  • Интуитивно-понятный интерфейс EFI. Так называемая “простота управления”. Достаточно спорный момент, невозможно однозначно отнести его к плюсу или минусу. Утверждается, что управление BIOS было не интуитивно, представляя собой плохо документированный, аскетичный текстовый интерфейс, разобраться в котором мог только подкованный в компьютерных технологиях пользователь. В противовес этому, во многих оболочках EFI поддерживаются графический интерфейс, манипулятор “мышь”, которые в большинстве BIOS просто не реализованы. Однако, если мне не изменяет память, я еще в 90-х годах наблюдал попытки реализации поддержки мыши в BIOS от (кажется) Phoenix. Сам интерфейс может быть графическим, по мнению некоторых - более дружелюбным и интуитивным для большинства, но может быть и традиционным, то есть схожим с классическим текстовым, тут все зависит от предпочтений разработчика и позиционирования оборудования. Имеется возможность поддержки нескольких языков.
  • Скорость работы EFI. Утверждается, что код UEFI выполняется быстрее кода традиционного BIOS (хотя и написан на C), за счет того, что целиком написан “с нуля”, без необходимости "волочить" за собой обоз устаревшего кода поддержки различного нестандартного железа и разнообразных логических анахронизмов.
  • Скорость загрузки ОС. Утверждается, что с EFI загрузка происходит существенно быстрее. Достигается это за счет распараллеливания инициализации устройств, в противоположность BIOS, который инициализировал оборудование последовательно, а так же уменьшения времени запуска, из-за отсутствия необходимости искать загрузчик методом перебора всех устройств (загрузчик указывается в EFI и вызывается непосредственно). Склонен верить, поскольку подтвердить либо опровергнуть на данный момент не могу. Однако, если засечь, сколько времени уходит на моей старой машинке на Celeron 450/GA-G31M-ES2L с SSD с момента включения и до появления окна авторизации оптимизированной Windows XP, то проходит всего 23 секунды. Вероятно, кому то это покажется недостаточным.
  • EFI - мини ОС. Можно, конечно же, обозвать EFI миниатюрной операционной системой, и это, от части, будет справедливо, но корректнее считать её виртуальной платформой, которая предоставляет интерфейсы к оборудованию. Можно работать только в консоли, а можно написать и полноценный графический интерфейс. UEFI, при наличии модулей необходимого функционала, может, к примеру, помочь разобраться в проблемах загрузки основной ОС, или выполнить другие сервисные функции.
  • Дополнительные программные модули. До загрузки ОС, EFI позволяет запускать собственные EFI-модули и драйвера различного назначения: по работе с сетью, диском (архивация/бэкап/антивирус), конфигурацией прошивки, по тестированию оборудования. Список подобных EFI-приложений со временем будет только расширяться. Можно даже написать полноценную игру. Можно разработать собственную консоль для системных нужд в виде отдельного EFI-модуля (shell.efi), что дает возможность организовать, например, выход в интернет, просмотр фильмов, прослушивание музыки или резервное копирование дисков.
  • EFI содержит встроенный менеджер загрузок. То есть, реализует собственный загрузчик кода ОС, который очень функционален и может выступать аналогом знакомых нам по не столь далекому прошлому мультизагрузчиков нескольких операционных систем.
  • Размер блока ввода-вывода. В UEFI при чтении используется особый размер блока EFI ввода-вывода, позволяющий читать по 1Мб данных за раз (в BIOS ограничение – 64Кб).
  • Безопасность. Якобы UEFI защищена от вредоносного кода этапа загрузки. Утверждается, что вредоносный код не может загрузить себя до загрузки операционной системы, перехватив тем самым управление. Это достигается и за счет подписывания всего подряд в самой прошивке, так и за счет существования безопасной процедуры загрузки под названием “Secure Boot”.
  • Простота расширения функционала. Прошивка UEFI может легко расширяться - достаточно вставить поддерживаемый накопитель (к примеру USB-флешку). После этого с внешнего устройства можно подключить дополнительные драйверы, приложения UEFI. Если подумать, тем самым открываются прекрасные возможности расширения функционала, которые нельзя было получить с помощью традиционного BIOS, поскольку он был ограничен зашитым в ROM кодом. В UEFI же можно подсунуть драйвер новой железки непосредственно еще на стадии работы UEFI, то есть до ОС, и получить доступ к функционалу этого устройства.
  • Код UEFI функционирует в 32-/64-битном режиме. Со всеми вытекающими .. преимуществами. Если быть уж совсем честным, то всё же UEFI использует реальный режим в самом начале для выполнения некоторых задач инициализации платформы, однако очень быстро уходит в защищенный/длинный режим.
  • Поддержка альтернативных средств ввода. UEFI обеспечивает поддержку альтернативных средств ввода данных, таких как виртуальные клавиатуры и сенсорные дисплеи. Это достаточно актуально в нашу эпоху различных мобильных гаджетов.

Недостатки

  • Усложнение архитектуры. Все преимущества EFI не являются настолько уж значимыми перед основным её недостатком - усложнением структуры кода. Значительное увеличение объема кода, его логическое усложнение никак не способствуют облегчению разработки, скорее даже наоборот. А ведь до и параллельно с UEFI, альтернативой устаревшей модели BIOS были открытые реализации, к примеру OpenBIOS, которые были отвергнуты.
  • Secure Boot. Тут разработчики операционных систем решили сразу несколько проблем: частично проблему пиратства, исключив обход активации путем внедрения активаторов в этапы загрузки, проблему вредоносного кода (вирусов) стадии загрузки и проблему очень уж популярных старых ОС, с которых ну никак не хотят слезать пользователи. В действительности вышло так, что в отдельных особенно умных устройствах, из-за наличия не отключаемой опции "Secure Boot", зачастую невозможно установить никаких ОС кроме операционных систем линейки Windows начиная с версии 8, поскольку сертифицированные загрузчики на данный момент имеют лишь они. Согласитесь, смахивает на довольно топорный способ борьбы со скупыми пользователями и конкурентами, хотя сама Microsoft всячески отрицает подобную ситуацию. Одним словом, технология способна доставить массу неудобств, хорошо хоть у большинства вендоров эта опция (пока еще) отключается в настройках.
  • Невозможность установки старых ОС (в некоторых случаях). Невозможно установить старые системы при отсутствии режима совместимости (CSM).
  • Отступление от стандарта. Каждый производитель аппаратных компонентов по своему усмотрению модифицирует UEFI, тем самым создавая для пользователя дополнительные трудности. Возвращаемся в хаос BIOS? Например, на различных устройствах менеджер загрузки может быть реализован по-разному, при этом иметь достаточно существенные отступления от рекомендаций спецификации UEFI. На практике, иногда попадались забагованные UEFI, которые игнорировали параметры списка загрузки NVRAM и просто грузили код из \EFI\Microsoft\Boot\bootmgfw.efi или EFI/BOOT/bootx64.efi. Или менеджер загрузки в одних реализациях может содержать комбинированный список из MBR и GPT устройств, в других же разные списки загрузки, что вводит некоторую сумятицу.
  • Внедрение средств контроля контента. Стандарт UEFI предусматривает наличие неких драйверов, которые будут перехватывать вызовы операционной системы, таким образом можно реализовать DRM (Digital Restrictions Management, технические средства защиты авторских прав). Суть алгоритма следующая: человеку, у которого все работает, предлагается за его же счет установить такое программное обеспечение или оборудование, чтобы часть функций в его работающих системах воспроизведения цифрового контента (компьютеры, мультимедиа-плееры и др.) более не работала привычным образом. Существуют небезосновательные опасения, что создание UEFI - это завуалированный способ введения в ПК нежелательных для конечного пользователя функций.
  • Возможность внедрения нежелательных модулей. Невозможно гарантировать, что операционная система на 100% контролирует компьютер, если она загружается с помощью UEFI!
  • Хаос разработки. Объясняется наличием у производителя материнской платы собственных технологий. Естественно, что каждый производитель стремится сделать свои решения уникальными, обладающими какими-либо "инновационными" технологиями, которые присущи только лишь его собственным разработкам. Поэтому, в любом случае, каждый производитель вынужден будет разрабатывать уникальные модули UEFI для своих прошивок. Поэтому все-равно каждый раз придётся писать уникальный код в собственных приложениях и драйверах UEFI, а потом монотонно исправлять там баги. В какой-то мере, опять возвращаемся к проблемам, присущим разработке BIOS[3].

BIOS&UEFI

Отличия процесса загрузки BIOS и UEFI

UEFI может использовать универсальную исполняющую машину вроде JVM для использования аппаратно-независимого кода, а это открывает огромные горизонты для создания «загрузочного» ПО (см. рис. 1).

Рисунок 1 - Отличие процесса загруки BIOS и UEFI

Источники

  1. UEFI - Унифицированный расширяемый микропрограммный интерфейс // Блог по Windows. Дата обновления: 29.04.2015. URL: http://datadump.ru/uefi/ (дата обращения: 14.09.2018).
  2. Что такое EFI / UEFI ? // Serty [2005––2016]. URL: http://serty.ru/info/articles/kompyutery/Chto-takoe-EFI-UEFI/ (Дата обращения: 20.05.2017)
  3. EFI // Alterbit URL: http://www.alterbit.ru/glossary178.html (Дата обращения: 14.09.2018)