Унифициран разширяем интерфейс за фърмуер (UEFI)

Унифицираният разширяем интерфейс за фърмуер (UEFI, произнася се U-E-F-I) e спецификация която създава софтуерен интерфейс между операционната система и платформения фърмуер. UEFI е предназначен да замени интерфейса на BIOS фърмуера, който се намира на всички персонални компютри, съвместими с IBM PC.

На практика повечето интерфейси на UEFI също поддържат BIOS услуги. UEFI поддържа дистанционна диагностика на грешки и дори решава компютърни проблеми без операционна система.

Оригиналната EFI (Extensible Firmware Interface или Разширяем Фърмуер Интерфейс) спецификация е разработена от Intel. Някои от практиките и форматирането на данни на EFI копират тези на Microsoft Windows. През 2005 UEFI отхвърли EFI 1.10 (последната версия на EFI). Индустрията която управлява UEFI спецификациите е Унифицирания EFI Форум(The Unified EFI Forum). 

Логото на UEFI

Позицията на EFI в софтуерния стек

История

Основната мотивация за създаването на EFI е идва по време на ранните стадии на разработка на първите Intel-HP Itanium системи, през средата на 1990. Ограниченията на BIOS (като 16-битовия режим за процесор, 1 MB адресируемо пространство и PC AT хардуерът) тогава са започнали да стават прекалено ограничителни за по-големи сървърни платформи, които Itanium набелязва. Усилията да се обърне внимание на тези опасения, започват през 1998 и са първоначално наречени Intel Boot Initiative и по късно преименувани на EFI.

През Юли 2005, Intel спират разработката върху EFI спецификация с тогавашна версия 1.10 и я предават на Unified EFI Forum, който доразработва спецификацията до Унифицирания Разширяем Фърмуер Интерфейс (UEFI). Оригиналната EFI спецификация е все още притежавана от Intel, които предоставят лицензи единствено и само за EFI – базирани продукти, докато UEFI спецификацията е притежавана от Unified EFI Forum.

Версия 2.1 на UEFI (Унифицирани Разширяем Интерфейс за Фърмуер) спецификацията, е издаден на 7 януари 2007. В нея биват добавяни криптография, мрежова автентикация и потребителската интерфейсна структура (позната като Human Interface Infrastructure в UEFI). Последната UEFI спецификация, версия 2.8, е одобрена през Март 2019.

Предимства

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

• Възможността да зарежда (boot) от по големи твърди дискове (над 2 TB) с GPT (GUID Partition Table)
• Независима архитектура от централния процесор.
• Независими драйвери от централния процесор.
• Гъвкава пред-операционно-системна среда, включваща възможност за мрежови дейности.
• Модулярен дизайн

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

Съвместимост на процесори

До версия 2.8 се поддържат само процесори от тип „little-endian“. Съществуват процесорни връзки за Itanium, x86, x86-64, ARM (AArch32) и ARM64 (AArch64)

Стандартния PC BIOS е ограничен до 16-битов режим на процесора и 1 MB адресируема памет, поради това, че дизайнът му е базиран на IBM 5150 моделът, който използва 16-битов Intel 8088 процесор. В сравнение, процесорът създаден в UEFI среда може да бъде или 32 битов (x86-32, AArch32) или 64 битов (x86-64, Itanium, and AArch64). 64-битовата UEFI фърмуер имплементация поддържа дълъг режим (long mode), който позволява на приложения в пред-зареждащата изпълнима среда да използват 64-битово адресиране за да имат директен достъп до пълната памет на машината.

UEFI изисква фърмуерът и зареждача на операционната система да имат сходен размер. Например 64 битова UEFI фърмуер имплементация може единствено да зареди 64-битов зареждач за операционна система. След като системата премине от „Boot услуги“ към „Изпълняващи услуги“, работата се прехвърля върху ядрото на операционната система. В този момент, ядрото може да сменя процесорни режими при нужда, но това пречи на изпълняваните услуги. От версия 3.15, ядрото на Linux поддържа стартиране на 64 битови ядрото на 32-битова UEFI фърмуер имплементация, работеща върху x86-64 CPU с UEFI поддръжка от UEFI boot зареждач, според изискването. Превключващият UEFI протокол дублира кода на UEFI инициализацията между кернела и UEFI boot зареждача, оставяйки инициализирането да бъде извършено само от ядрото на Linux – UEFI boot stub.

Съвместимост на дискови устройства

В допълнение на стандартното деление на PC дисковете, което използва master boot record (MBR) UEFI работи и с нов модел на делене наречен GUID Partition Table (GPT), който няма много от ограниченията на MBR. По конкретно, MBR ограничава размера и броя на делението на дискове (до 4 главни деления на диск и до 2TiB(2 × 2⁴⁰ байтове) за диск). По точно GPT позволява максимален размер на делене на диска от 8 ZiB (8 × 2⁷⁰ байта)

Linux

Поддръжка за GPT в Linux се разрешава чрез включване на настройката CONFIG_EFI_PARTITION по време на конфигурация на кернела. Тази настройка позволява на Linux да разпознае и използва GPT дисковете след като системния фърмуер предаде контрол от системата на Linux.

За обратна съвместимост Linux може да използва GPT дискове в BIOS – базирани системи за съхранение на данни и boot-ване, тъй като и двете системи, GRUB 2 и Linux, разпознават GPT. Такава процедура обикновено се нарича BIOS-GPT. Когато GPT внедри защитния MBR, BIOS-базиран компютър може да се зареди от GPT диск, като използва GPT-съвместим boot зареждач, съхранен в кодовата част на фърмуера на MBR. GRUB конфигурацията изисква BIOS Boot дял, за да може GRUB да внедри вторичния си код, поради липса на следваща-MBR дупка в GPT разделен диск. Често с размер от 1 MiB, GUID-a(Globally Unique Identifier) на схемата на дяла в GPT е 21686148-6449-6E6F-744E-656564454649 и е използвана от GRUB само в BIOS-GPT настройки. От перспективата на GRUB, такъв дял не съществува в случай на MBR подялба. Този дял не е нужен, ако системата е UEFI – базирана, защото няма нужда от внедряване на вторичния код.

UEFI системите могат да използват GPT дискове и да се зареди направо от тях, което позволява на Linux да използва UEFI зареждащи методи. Зареждането на Linux от GPT дискове включва създаването на дял от EFI системата (EFI system partition – ESP), която съдържа приложения от типа на boot – зареждачи, ядра на операционни системи и софтуер за удобство. Такива настройки обикновено биват наричани UEFI-GPT, но ESP-то е препоръчително да бъде поне 512 MiB и форматирано с FAT32 файлова система за максимална съвместимост.

За обратна съвместимост повечето UEFI реализации също поддържат зареждане от MBR-разделени дискове, през "модул за поддръжка на съвместимостта" (Compatibility Support Module), която осигурява съвместимост със стария BIOS. В такъв случай, зареждането на Linux на UEFI системи е същото, както на системи базирани на стария BIOS.

Microsoft Windows

64-битовите версии на Microsoft Windows Vista и по-нови, 32-битовите версии на Windows 8 и по-нови и Itanium версиите на Windows XP и Server 2003 могат да се зареждат от дискове с дял по-по голям от 2 TB.

Особености

Услуги

EFI дефинира два вида услуги: зареждащи и услуги в реално време. Зареждащите услуги са достъпни само когато платформата принадлежи на фърмуера (преди да се получи ExitBootServices – команда) и включват текстови и графични конзоли на различни устройства, като и шини, блокови и файлови услуги. Услугите в реално време са достъпни и когато се изпълнява операционната система. Включени са услуги като дата, време и достъп до NVRAM.

В допълнение, "графичен изходящ протокол" (Graphics Output Protocol, GOP) предоставя ограничена поддръжка на услуги в реално време. Операционната система може да прави промени директно върху кадровия буфер (framebuffer) предоставен от GOP (графичен изходящ протокол) в реално време. Способността да сменя видео режими се губи след смяната на режима на услуги в реално време, докато графичния драйвер на операционната система не се зареди.

Услуги за променливи

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

Времеви услуги

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

Приложения

Независимо от зареждането на операционната система, UEFI има способността да зарежда самостоятелни UEFI приложения, които могат да бъдат разработени и инсталирани независимо от производителя на системата. UEFI приложенията пребивават като файлове на ESP и може да се стартират директно от стартиращия мениджър на фърмуера, или чрез други приложения UEFI. Един клас от UEFI приложенията са зареждащите операционната система, като rEFInd, Gummiboot и Windows Boot Manager; те стартират конкретна операционна система и евентуално предоставят потребителски интерфейс за избор на стариране друго приложение UEFI. Utilities, също като UEFI shell, представляват UEFI приложения.

Протоколи

EFI дефинира протоколи като набор от софтуерни интерфейси, използвани за комуникация между два двоични модула. Всички EFI драйвъри трябва да предоставят услуги на другите чрез протоколи.

Драйвери за устройства

В допълнение към стандартната специфична архитектура на драйвери за устройства, EFI спецификацията предоставя драйвер за устройство независимо от средата на процесора, наречена EFI байт код или EBC. Системен фърмуер се изисква от спецификацията на UEFI за извършване на интерпретации за всякакви EBC изображения, които се намират в или са заредени в средата. В този смисъл, EBC е аналогичен на Open Firmware, на хардуерно независим фърмуеър, използван в PowerPC базирани Apple Macintosh и Sun Microsystems SPARC компютри.

Някои архитектурно-специфични (не-EBC) EFI устройства могат да имат интерфейс за използване от операционната система. Това позволява на операционната система да разчита на EFI за основни графични и мрежови функции, докато специфични за операционната система драйвери са заредени.

Графични особености

EFI спецификацията определя UGA (Универсален Графичен Адаптер) протокол като начин за подкрепа на независими от устройства графики. UEFI не включва UGA и го заменя с GOP (Графично Производствен Протокол), с цел премахване VGA хардуерни зависимости. Двете са подобни.

UEFI 2.1 определя „Човешка интерфейс инфраструктура“ (HII) за управление на потребителските въвеждания, локализирани низове, шрифтове и форми (във връзка с HTML). Това дава възможност за производители на оригинално оборудване (OEM) или независими доставчици на BIOS (IBVs) да проектират графични интерфейси за конфигурация на предварително зареждане; Самото UEFI не дефинира потребителски интерфейс.

Най-ранните UEFI фърмуер реализации са базирани на конзолна основа, но още преди 2007 година някои реализации включват графичен потребителски интерфейс. 

EFI Системен дял

EFI Системен дял, често съкращавам като ЕSP, e дял за устройства за съхранение на данни, който се използва при компютри придържащи се към спецификацията на UEFI. Използван от фърмуерът на UEFI, когато компютърът е включен, съхранява UEFI приложения и файловете, които тези приложения трябва да изпълнят, включително ядрата на операционната система. Поддържани схеми за разделителна таблица включват MBR и GPT, също така и El Torito обеми за оптични дискове. За използването на ESP-та, UEFI дефинира специфична версия на FAT файловата система, която се поддържа като част от спецификацията на UEFI и е независима от оригиналната спецификация на FAT. Обхваща вариант на FAT32 файлова система за ESP-та, и FAT16 и FAT12 файлови системи за преносими носители. ЕSP също осигурява пространство за сектор за стартиране като част от обратната съвместимост на BIOS.

Стартиране

UEFI стартиране

За разлика от BIOS, UEFI не разчита на сектор за начално зареждане, вместо това дефинира мениджър за стартиране като част от спецификацията си. При включване на компютъра, мениджърът за стартиране проверява конфигурацията за стартиране, и според нейните настройки зарежда и изпълнява определеният стартер на операционна система или ядро на операционна система. Конфигурацията за стартиране е комплект от променливи на глобална основа, заложени в NVRAM, включително променливите за стартиране, които сочат към пътищата до стартерите на операционна система и ядрата. Като клас от компоненти на приложения на UEFI, те са съхранени като файлове във фърмуерно-достъпния EFI Системен дял (ESP).

Стартерите на операционна система могат автоматично да бъдат засечени от UEFI имплементация, която позволява лесно стартиране от преносими устройства като USB флаш. Това автоматично откриване разчита на стандартизиран файлов път до стартера на операционна система, като пътят зависи от компютърната архитектура. Форматът на файловия път е дефиниран като <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; Например файловият път до зареждача на х86-64 система е /efi/BOOT/BOOTX64.EFI. 

Стартирането на UEFI системи от GPT-разделени дискове е често наричано UEFI-GPT. Също е често срещано UEFI имплементацията да включва потребителски интерфейс с меню към мениджъра за стартиране, позволяващ на потребителя ръчно да избере желаната операционна система (или системно устройство) от списък с позволени опции за зареждане.

CSM стартиране

За да се осигури обратна съвместимост, повечето UEFI имплементаций на фърмуер на PC-клас машини също поддържат стартиране в legacy(завещан) BIOS режим от MBR-разделени дискове, през Модула за Поддържане на Съвместимост (CSM), който осигурява legacy BIOS съвместимост. В този сценарий, стартирането е извършено по същият начин както на legacy BIOS-базирани системи, като се игнорира разделителната таблица и се разчита на съдържанието на сектор за стартиране.

Стартирането в стила на BIOS от MBR разделени дискове е често наричано UEFI-MBR, независимо дали се извършва от UEFI или от legacy BIOS-базирани системи. Освен това, стартирането на завещани BIOS-базирани системи от GPT дискове също е възможно, такава схема за стартиране често е наричана BIOS-GPT.

Въпреки факта, че UEFI спецификацията изисква MBR разделителна таблица, за да бъде напълно поддържана, някои имплементаций на фърмуер на UEFI незабавно превключват в BIOS-базиранао CSM стартиране, което зависи от типа на разделителната таблица на стартирания диск, което ефективно спира UEFI стартинането да бъде извършено от EFI Системни дялове върху MBR-разделени дискове. Такава схема за стартиране често е наричана UEFI-MBR

Мрежово стартиране

Спецификацията на UEFI включва поддръжка за зареждане през мрежа чрез Preboot eXecution Environment (PXE). В основата на мрежовите протоколи се включват Интернет Протокол (IPv4 и IPv6), User Datagram Protocol (UDP), Dynamic Host Configuration Protocol (DHCP) и Trivial File Transfer Protocol(TFTP)

Също е включена поддръжка за достъп до изображение по време на стартиране, които автоматично се запазват в мрежи за съхранение на данни (SANs), с Малък Интернет Интерфейс на Компютърна Система(iSCSI) и Фибърен Канал през Eтернет(FCoE) като поддържани протоки за достъп до SANs.

Версия 2.5 на спецификацията на UEFI добавя поддръжка за достъп до изображения по време на стартиране през HTTP протоколът.

Защитено стартиране

Спецификацията на UEFI 2.2 добавя протокол познат като защитено стартиране, който защитава процеса на стартиране като спира зареждането на драйвери или стартери на операционна система, които не регистрирани с приемлив дигитален подпис. Когато защитеното стартиране е позволено, то е поставено в „режим на настройване“, което позволява публичен ключ, познат като „Платформен ключ“ (PK) да бъде написан до фърмуерът. Веднъж щом ключът е написан, защитеното стартиране влиза в „Потребителски режим“, където само драйвери и стартери регистрирани с платформения ключ могат да бъдат заредени от фърмуерът. Допълнителни „Ключови ключове за обмен“ (KEK) могат да бъдат добавени до база данни запазена в паметта, за да се позволи други сертификати да бъдат използвани, но те трябва да имат връзка до частната връзка на Платформения ключ. Защитеното стартиране може да бъде поставено и в „Променлив“ режим, където допълнителни ключове могат да бъдат добавени в системата, дори да не съответстват с частния ключ.

Защитеното стартиране се поддържа от Windows 8 и 8.1, Windows Сървър 2012 и 2012 R2 и няколко Linux дистрибуции, включително Fedora (от версия 18), openSUSE (от версия 12.3), Ubuntu (от версия 12.04.2). От Юни 2015, FreeBSD поддръжка е в състояние на планиране.

Модул за поддържане на съвместимост

Модулът за Поддържане на Съвместимост (CSM) е компонент на фърмуерът на UEFI, който осигурява завещана BIOS съвместимост като подражава на средата на BIOS, позволявайки на завещани операционни системи и някой опционални ROM-ове, които не поддържат UEFI да бъдат използвани.

CSM също осигурява функционалност за нужен завещан Режим за Системно Управление (SMM), наречена CompabilitySmm, като допълнителна характеристика, осигурена от UEFI SMM. Tя е избираема, много специфична за чипсети и платформи. Пример за такава завещана SMM функционалност е осигуряването на завещано поддържане на USB-та за клавиатури и мишки, чрез подражаване на класическите PS/2 елементи.

UEFI обвивка

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

Програмният код за обвивката на UEFI може да бъде свален от проектът на Intel – TianoCore UDK2010 / EDK2 SourceForge. Втората версия на обвивката работи най-добре със системи UEFI 2.3+ и се предпочита пред първата версия на обвивката на UEFI за тези системи. Първата версия на обвивката трябва да работи на всички системи на UEFI.

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

Разширения

Разширения до EFI могат да бъдат заредени виртуално от всяко енергонезависимо записващо устройство свързано с компютъра. Например, първоначалният пройзводител на оборудването (ОЕМ) може да разпространи системи с дял за EFI на твърдия диск, което ще добави, допълнителни функции към стандартните EFI фърмуери, записани на ROM-a на дънната платка.

Имплементантация и приспособление

Intel EFI

Имплементацията на Intel за EFI е Intel Platform Innovation Framework, с кодово име „Tiano“. Tiano е имплементиран в XScale, Itanium и IA-32 процесорите на Intel и не е с отворен код, въпреки че част от кода е публикуван под BDS или EPL лиценз с името TianoCore. Това ядро може да бъде използвано като основа за coreboot.

Имплементацията на Phoenix Technologies за UEFI включва SecureCore и SecureCore Tiano. Други които имат свои имлементации на Tiano са: American Megatrends със своя Aptio и Insyde Software с InsydeH2O.

Платформи използващи EFI/UEFI

Първите Itanium работни станции и сървъри на Интел, пуснати през 2000 година са използвали EFI 1.02.

През 2002 година са пуснати Itanium 2 системи на Хюлет-Пакард, които имплементират EFI1.10. Те са могли да заредат Windows, Linux, FreeBSD и HP-UX; OpenVMS са добавили UEFI като способност през юни 2003 година.

През януари 2006 година, Apple Inc. доставят първите си Intel – базирани Macintosh компютри. Tези системи, използвали EFI вместо Open Firmware, които са били използвани за предишните PowerPC – базирани системи.

На 5 април 2006 г. Apple за първи път пускат Boot Camp, който възпроизвежда Windows драйвер диск и недеструктивен инструмент за разделяне с цел позволяването на инсталация на Windows XP или Vista без да е нужна преинсталация на Макинтоша.

През 2011 г. големи доставчици (като ASRock, Asus, Gigabyte, и MSI) стартираха производството на дънни платки, използващи Intel 6 – серия LGA 1155 чипсет и AMD AM3 + 9 Series чипсети с UEFI.

С пускането на Windows 8 през октомври 2012 г., Microsoft вече изискват, фърмуер, който да реализира спецификацията на UEFI. Освен това, ако компютърът поддържа функцията на Windows 8 „Connected Standby“ (който позволява на устройствата да имат опция за управление на захранването, сравнима с тази на смартфоните, която почти незабавно връща телефона от режим на готовност), то след това на фърмуера е забранено да съдържа Compatibility Support Module (CSM). С други думи, системи, които поддържат свързан режим на готовност (Connected Standby) са неспособни да стартират по-стари версии на BIOS.

Oперационни системи

• От началото на 2000 г., ядрото на Linux е било в състояние да използва EFI по време на зареждане. Пример за това е по-скорошната версия на EFI GRUB. Grub + Linux, могат да бъдат заредени чрез GUID, без да се налага използването на UEFI.
• HP-UX е използвал (U)EFI като стартиращ механизъм за IA-64 системи от 2002 година.
• HP OpenVMS използват (U)EFI на IA-64 от първонанчалното му пускане през 2003 година и го пускат за масова продукция през януари 2005 г.
• Apple използват EFI върху Intel-базираните си макове. За пример: Mac OS X v10.4 Tiger и Mac OS X v10.5 Leopard имплементират EFI v1.10 в 32 – битов режим дори и на по-новите 64-битови процесори, но пълната версия пристигна с Mac OS X v10.8 Mountain Lion.
• Итаниум версиите на Windows 2000 (Advanced Server Limited Edition and Datacenter Server Limited Edition) също са използвали EFI 1.10 през 2002 година. MS Windows Server 2003 за IA – 64, MS Windows XP 64-битова версия и Windows 2000 Advanced Server Limited Edition, всички от които са в семейството на Intel Itanium процесори, използват EFI.
• Microsoft въвежда UEFI за x86-64 операционни системи с Windows Server 2008 и Windows Vista Service Pack 1, така че 64-битовите версии на Windows 7 да бъдат съвместими с EFI. От друга страна, 32 – битовата версия на UEFI не е била поддържана, тъй като продавачите не са имали интерес в производството на 32 – битови версии фърмуер заради голямата популярност на 64 – битовите компютри. По-късно, Windows 8 включва допълнителна оптимизация за UEFI системи, включително, по-бързо пускане, 32-битова версия и безопасно стартиране (secure boot support).
• На 5 март 2013 г., Фондацията FreeBSD награди разработчик, който се е опитал да направи поддръжка на UEFI в ядрото в FreeBSD. Първоначално кода е бил съхранен на отделно място, но през 4 април 2014 г. е бил пуснат в употреба. Промените включват и поддръжка в инсталатора.
• Oracle Solaris 11.1 и по-късно поддръжка на UEFI са направени за x86 системи с версия на фърмуера UEFI 2.1, в това отношение, GRUB 2 е използван като стартиращ механизъм за x86.

Използване на UEFI с виртуализация

• Интегритетът от виртуални машини на HP (на английски: HP Integrity Virtual Machines) предлага стартиране на UEFI платформа върху сървъри на HP, както и среда за гости на UEFI-aware Oses.
• Intel е домакин на отворен виртуален фърмуерен проект (на английски: Open Virtual Machine Firmware) на SourceForge.
• Софтуерът на VMware Fusion 3 може да стартира Mac OS X сървъри, използвайки EFI. Работната среда на VMware поддържа (неофициално) EFI, но трябва да се пусне ръчно и до този момент (2012 г.) безопасното стартиране, (Secure Boot) все още не се поддържа. От друга страна ESXi/vSphere 5.0 официално поддържат UEFI.
• VirtualBox имплементира UEFI от версия 3.1, но е лимитирана само до операционните системи на Unix и Линукс.
• QEMU може да се използва с Open Virtual Machine Firmware (OVMF), предоставен от TianoCore.
• VMware ESXi версия 5, която е част от VMware vSphere, поддържа виртуализирана EFI платформа като алтернатива на BIOS.
• Второто поколение на Майкрософт Hyper – V (виртуална машина) поддържа UEFI.

Развитие на приложения

Инструментите за развиване на приложения EADK (Application Development Kit (EADK2)) дава възможност да се използва стандартна C библиотека (standard C library) в апликациите на UEFI. EADK може да бъде изтеглен безплатно от проекта на Intel's TianoCore UDK2010 / EDK2 SourceForge. Като пример, порт на интерпретатора на Питон (Python) може да се използва като UEFI приложение, благодарение на EADK.

Пример за сходство между програма, написана на EADK и C:

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

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

Критика

Многобройни активисти на дигиталните права (digital rights activists) са протестирали, с течение на години, срещу UEFI. В това число, Роналд Г. Миних, съавтор на Coreboot, Кори Доктороу, активист, който е разкритикувал EFI като опит да премахне възможността на потребителя напълно да контролира компютъра си. UEFI, например, не е успял да разреши дългогодишните проблеми на BIOS за нуждата от двата типа драйвери – единия за фърмуер и другия за операционната система.

Проект с отворен код TianoCore (Open source project TianoCore), също предоставя употребата на UEFI интерфейс. TianoCore не разполага със специализирани драйвери, които инициализират функциите на чипсета, който от друга страна е предоставен от Coreboot, от който TianoCore е една от многото платени опции. Развитието на Coreboot изисква съдействие от страна на производителите на чипсети, необходимо за развитието на драйверите.

На конференцията Black Hat през август 2013 г., група от изследващи сигурността представят поредица от търговски разработки в конкретни реализации на UEFI, които могат да бъдат използвани в оптимизирането на защитеното зареждане.

Windows 10 ще позволи на оригиналните производители на оборудване да не предлагат възможност за конфигуриране или забрана на защитеното зареждане на x86 системи. 

Проблеми около фърмуера

Увеличената известност на UEFI фърмуера за устройствата води до редица технически проблеми, свързани със съответното си изпълнение.

След излизането на Windows 8 в края на 2012 г., се установява, че някои модели компютри на Lenovo със защитено зареждане имат фърмуер, който е кодиран да позвоява да се зареждат само изпълними (executable) файлове с име „Windows Boot Manager“ или „Red Hat Enterprise Linux“, независимо от всякаква друга настройка. Други проблеми възникват с няколко модели лаптопи на Toshiba със зашитено зареждане, които показват, че са изчезнали някои сертификати, необходими за правилното му функциониране.

През януари 2013 г., е публикуван бъг, който заобикаля изпълнението на UEFI на някои лаптопи Samsung, което ги кара да се блокират след инсталиране на Linux в режим UEFI. Докато потенциални конфликти с модули на ядра, предназначени за достъп до системните функции на лаптопи на Samsung първоначално биват обвинявани (също подтикващи поддръжката на ядрото да изключва модула за UEFI системи като мярка за безопасност), Matthew Garrett разкрива, че този бъг всъщност се задейства като съхранява твърде много UEFI променливи в паметта, и че този бъг би могъл да бъде задействан и под Windows при определени условия. В заключение, той заявява, че модулът на нарушаващото ядро причинява пропуски в съобщението на ядрото да бъдат изписани на фърмуера, като по този начин се предизивква бъг.

Вижте също

• Стартиране (компютри)
• BIOS

Източници

Тази страница частично или изцяло представлява превод на страницата Unified_Extensible_Firmware_Interface в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​ ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​