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

от Уикипедия, свободната енциклопедия
Направо към: навигация, търсене

Унифицираният разширяем интерфейс за фърмуер (UEFI, произнася се U-E-F-I) e спецификация която създава софтуерен интефрейс между операционната система и платформения фърмуер. UEFI заменя основния Вход/Изход системен (BIOS) фърмуер, поначало наличен във всички IBM-PC – съвместими персонални компютри със повечето UEFI фърмуерни имплементации предоставящи legacy поддръжка за 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.5, е одобрена през Април 2015.

Предимства[редактиране | редактиране на кода]

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

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

Съвместимост[редактиране | редактиране на кода]

Съвместимост на процесори[редактиране | редактиране на кода]

До версия 2.5 се поддържат само процесори от тип „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 × 240 байтове) за диск). По точно, GPT позволява максимален размер на делене на диска от 8 ZiB (8 × 270 байта)

Linux[редактиране | редактиране на кода]

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

За обратна съвместимост, Linux може да използва GPT дискове в BIOS – базирани системи за съхранение на данни и boot-ване, тъй като и двете системи, GRUB 2 и Linux, разпознават GPT. Такава процедура обикновено се нарича BIOS-GPT . Когато GPT внедри защитния MBR, BIOS-базиран компютър може да се boot-не от 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 дискове и да се boot-нат директно от тях, което позволява на Linux да използва UEFI boot-ващи методи. Boot-ването на Linux от GPT дискове включва създаването на дял от EFI системата (EFI system partition – ESP ), която съдържа приложения от типа на boot – зареждачи, ядра на операционни системи и софтуер за удобство. Такива настройки обикновено биват наричани UEFI-GPT, но ESP-то е препоръчително да бъде поне 512 MiB и форматирано с FAT32 файлова система за максимална съвместимост.

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

Microsoft Windows[редактиране | редактиране на кода]

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

Особености[редактиране | редактиране на кода]

Услуги[редактиране | редактиране на кода]

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

В допълнение, Графичния Изходящ Протокол (Graphics Output Protocol, GOP) предоставя ограничена поддръжка на услуги в реално време. Операционната система може да прави промени директно върху framebuffer-a предоставен от 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 без да е нужна преинсталация на Макинтоша.

По-късно е издаден и ъпдейт, който добавя съвместимост на BIOS за неговото прилагане в EFI. Следващите модели на Macintosh биват вече с нов фърмуер.

През 2005 г. повече от един милион Intel системи са направени с имплементация на UEFI. През 2006 г. започва доставката на нови телефони, монитори и сървърни продукти, използващи UEFI. Например, клавиатури, които са използвали Intel 945 чипсет, започват да използват фърмуер-а на UEFI.

От 2005 г. насам, EFI също е приложена върху не само компютърни архитектури, но и върху вградени системи и базирани на XScale ядра.

EDK (EFI Kit Developer) включва NT32, който позволява фърмуер-а и приложенията на EFI да работят в рамките на Windows, но директния достъп до хардуера е забранен от EDK NT32. Това означава, че само подмножество на EFI приложения и драйвери, могат да се изпълняват на EDK NT32.

През 2008 г., все повече x86-64 системи приемат UEFI. Докато много от тези системи все още позволяват стартиране само ОС BIOS (базирани на Support модул(CSM)), други системи, от друга страна, започнаха да позволяват стартиране чрез UEFI OSes. Примерно: IBM x3450 сървър, MSI дънни платки с ClickBIOS, всички HP EliteBook Notebook и Tablet PCs, по-новите версии на HP Compaq Notebook PCs (e.g., 6730b, 6735b, etc.).

През 2009, IBM доставят System x машини (x3550 M2, x3650 M2, iDataPlex dx360 M2) и BladeCenter HS22 със способност за UEFI. Dell от друга страна – PowerEdge T610, R610, R710, M610 и M710 сървъри, също поддържащи UEFI.

През 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перационни системи[редактиране | редактиране на кода]

Операционната система, която може да бъде заредена от (U)EFI се нарича (U)EFI – aware OS, определена от спецификациите на (U)EFI. В този случай, терминът „booted“ означава директно зареждане на системата с помощта на (U)EFI OS.

Местоположението по подразбиране за зареждането на операционната система е

<EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI

където кратките имена на съответната машина могат да бъдат IA32, X64, IA64, ARM или AA64. Някои дистрибутори на операционни системи могат да имат свой собствен начин за стартиране на системата, както и друго местоположение за зареждането на самата операционната система.

  • От началото на 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 изисква съдействие от страна на производителите на чипсети, необходимо за развитието на драйверите.

Защитено стартиране[редактиране | редактиране на кода]

През 2011 г., Microsoft обяви, че компютрите, сертифицирани да стартират своята операционна система Windows 8, трябва да се предлагат с активирано защитено зареждане с помощта на код за сигурност за Microsoft. След обявяването, компанията бе обвинена от критици и застъпници на безплатния софтуер (включително Фондацията за свободен софтуер), че се опитва да използва функцията за защитеното зареждане на UEFI като прикритие за целта да възпрепятства инсталирането на алтернативни операционни системи като Linux. Microsoft отрече, че изискването за защитено зареждане е предназначено да служи като форма на блокиране, и изяснени изискванията си посочвайки, че Intel-базирани системи, сертифицирани за Windows 8, трябва да позволяват защитеното зареждане да въвежда персонализиран режим или да бъде изключен, но не и върху системи използващи ARM структура.

Други разработчици изразиха загриженост относно правните и практически въпроси за прилагането на поддръжка за защитено зареждане върху Linux системи като цяло. Бившият разработчик на Red Hat Matthew Garrett отбелелязва, че условията на GNU General Public Version License 3, могат да предотвратят използването на GRUB буутлоудър без разработчика да разкрие кода за сигурност (по-късно Фондацията за свободен софтуер изяснява позицията си, гарантирайки, че отговорността да предоставят кодове за сигурност е на производителя на хардуер) и, че би било трудно за напреднали потребители да изграждане на поръчкови ядра, които могат да функционират с включено защитено зареждане без да са регистрирани. Други разработчици предполагат, че регистрирани продукти на Linux с друг код за сигурност могат да бъдат предоставени, но отбелязват, че би било трудно да бъдат убедени оригиналните прозиводители да предлагат своите компютри със задължителния код за сигурност заедно с този на Microsoft. 

Няколко основни Линукс дистрибуции са разработили различни реализации за защитено зареждане. Matthew Garrett разработва минимален буутлоудър известен като „подложка“, който е компилиран, регистриран буутлоудър, който позволява на потребителя индивидуално да се доверява на предоставени от дистрибутори кодове за сигурност. Ubuntu 12.10 използва по-стара версия на „подложката“ преконфигурирана за използване със собствен ключ на Canonical, който проверява само буутлоудъра и позволява нерегистрирани ядра да бъдат зареждани; разработчиците смятат, че практиката на регистриране само на буутлоудъра е по-възможно, тъй като доверено ядро е по-ефективно при осигуряване на потребителското пространство, а не на състоянието преди зареждането, за което защитеното зареждане е проектирано добавя защита. Това също така позволява на потребителите да изградят свои собствени ядра и да използват и други потребителски ядрени модули, без да е необходимо да преконфигурират системата. Canonical също поддържат собствен код за сигурност, за да верифицира инсталации на Ubuntu предварително инсталирани на сертифицирани от оригиналните производители компютри, които работят на операционната система, а също така планират да наложат изискване за защитено зареждане – изискващи едновременно кодове за сигурност наCanonical и Microsoft (от съображения за съвместимост) да бъдат включени в техния фърмуеър. Fedora също използва „подложка“, но изисква и ядрото и неговите модули да бъдат верифицирани.

Спори се дали ядрото и неговите модули трябва да бъдат верифицирани; докато спецификациите на UEFI не го изискват, Microsoft твърдят, че техните договорни изисквания го изискват, и че си запазват правото да отменят всички сертификати, използвани за верифициране на код, който може да се използва, за да компрометира сигурността на системата. През февруари 2013 , друг Red Hat разработчик се опитва да предостави пач на Linux ядрото, което би позволило да се направи съвместим с автентичния код на Microsoft с помощта на главен X.509 ключ вграден в PE файлове, сертифицирани от Microsoft. Предложението обаче бе критикувано от създателя на Linux Линус Торвалдс, който обвини Red Hat в подпомагане контрола на Microsoft над инфраструктурата на защитено зареждане.

На 26 март 2013 г., испанската група за безплатна разработка на софтуер Hispalinux подава официално оплакване до Европейската комисия твърдейки, че сигурни изискванията на Microsoft за защитено зареждане върху системи на оригинални производители са „обструктивни“ и неконкурентни.

На конференцията 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 при определени условия. В заключение, той заявява, че модулът на нарушаващото ядро причинява пропуски в съобщението на ядрото да бъдат изписани на фърмуера, като по този начин се предизивква бъг.

Вижте също[редактиране | редактиране на кода]

Източници[редактиране | редактиране на кода]

Криейтив Комънс - Признание - Споделяне на споделеното Лиценз за свободна документация на ГНУ Тази страница частично или изцяло представлява превод на страницата „Unified_Extensible_Firmware_Interface“ в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс - Признание - Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година — от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница. Вижте източниците на оригиналната статия, състоянието ѝ при превода, и списъка на съавторите.